On 3/3/08 6:23 PM, "Joonas Govenius" <[EMAIL PROTECTED]> wrote:
> What I don't like of the current SXE definition is the inability of
> sending the whole document or chunks it, instead of being obliged of
> sending all the necessary events for recreating the document.
If the extra bandwidth really is such a problem we could define an
implicit way of creating the objects out of a chunk of XML as I've
mentioned but it doesn't seem worthwhile to me at this point.
Boyd Fletcher wrote:
sending the entire document is a big show stopper for large group
collaboration (especially if you are using a large number of
whiteboard pages) and if your are using satellite/cellular
communications (like is very common in military or 3rd world countries).
we dealt with the problem by using sequence numbers and the client can
request which numbers it wants to receive.
You and Fabio are referring to slightly different issues here:
1. Fabio is concerned about the bandwidth used for sending the state to
a client when it first joins the session. It would be higher by some
significant constant factor so this is probably a legitimate concern but
could be solved as I mentioned above; I just think it would be a little
premature at this point.
2. You are concerned about optimizing reconnects by taking advantage of
the state that the client already has. I gave this some thought and
there's actually no reason why SXE couldn't do basically the same thing
as your protocol:
The client that reconnects would send a "last-received-sender",
"last-received-id", and "last-sent-id" that identify the last <sxe/>
element that it received and the last <sxe/> element that it sent.
Assuming that that "last-sent" element came through, the joiner would
then only receive edits sent by others after the "last-received" element.
Only the server-side reflector (or bot) would be required to accommodate
these requests though because the clients aren't required to remember
details about who sent which edits.
Joonas
