client/whiteboard

[red penguin]

Strok: expect a fla of the client in the next few minutes. It's working and I've added a few more things. Didn't clean it up though. There's a lot of extraneous codage and stuff and I haven't commented much.

Everyone else:
Whiteboard needs help. I have done it one way and I can't seem to redo it as my thinking is set on that way.

General idea of the whiteboard as of now:

It's set up to draw and record the necessary data.
Upon completion, user will choose a <target> and send. This has yet to be done, but I'd like to get the tranfer method first.
Info is sent and the 'playback' function evoked.
<target> sees drawing being drawn.

Issues here are that the data being sent will be three arrays.[list=1]
arr_lines : contains data points in a 2D array for lineTo( )
st_pts : the starting points. Captured on mouseDown
st_mark : starting mark. Used to compare to the indexes of arr_lines to know when to moveTo()
[/list=1]
These you can see in the file and see how they are used. This was integrated way back when and I haven't integrated the colors or size yet but that's no biggie.
:]

The other school of thought is to have it send the data in an almost real time fashion. onMouseDown would trigger a function to open the channel for transfer. Thus, the data isn't really saved in bulk, but rather sent immediately. So....

Anyway, I'm asking if anyone wants to jump in here with ideas for the data transfer.

The more minds on this, the faster it can get going. I'll be working on it tomorrow, so anyone with any thoughts, please reply to this thread and let's talk!

Thanks...
Pengs

attached : Zoomfreddy's redo in MX

[red penguin]

No takers?

I see five DL but no replies.

Red Penguin goes off to sit in the corner and wait.

[snowedin]

Wouldn't it depend on the server you use?

Assuming a java server passing xml objs -

Use a frame loop to send obj data - if changed,
or a button event.

mouseDown/Up might get messy.

Broadcast all sends to all clients.

obj data is a string made of your arrays, senderID, targetID.

If targetID is null or empty, all clients parse and draw the obj.

Else, only the targeted client and the sender will parse, draw.

The sender always receives it's own broadcast and overwrites
the obj it sent - so state is consistent for all clients, and if you're
saving state this is a good place to update a database.