Boyd Fletcher wrote: > > > On 2/4/08 6:09 PM, "Peter Saint-Andre" <[EMAIL PROTECTED]> wrote: > >> Boyd Fletcher wrote: >>> Access control is a big issue for collaborative whiteboarding as you have >>> read/write users, read only users, and users (like presenters) that can >>> control the presentation (i.e. page flips and who is writing/changing the >>> whiteboard). >> That should be handled by the floor control system (MUC or something >> else), not the editing technology (SXE or something else). > > I disagree. The whiteboarding component needs to understand what is going so > that it can maintain an accurate state of the whiteboard.
Layering. >>> Also, whiteboards are more than just a linear document of unrelated parts. >>> It has a very well defined structure and if a client sends out an >>> inappropriate/incorrect set of XML it can corrupt the entire whiteboard. SXE >>> can¹t prevent that but a pure server based implementation can. >> SXE in server mode can, but the spec does not yet define that in detail >> by showing server-mode examples. That can be fixed by beefing up the spec. >> >> Furthermore, SXE is now only the core editing protocol. Whiteboarding, >> collaborative document editing, and other technologies can be layered on >> top of SXE (the spec examples now show XHTML, not whiteboarding). >> > > that is a far more complicated approach so now you have to build a server > side SXE component then build a whiteboarding component that jacks into the > SXE component so that it properly handles the multitude of exceptions for > the whiteboard? sounds messy to me. What are all the exceptions for whiteboarding that don't apply to, say, XHTML editing? >>> we (and many large corporations) have operational experience and >>> requirements for large numbers (>100) of people collaborating actively in a >>> whiteboard session so not being able to handle that is a big deal. >> See above. SXE should be workable in server mode. It's a question of >> spec'ing that out more fully and building a working implementation that >> extends the client-to-client mode with a server in the middle that >> checks and (if necessary) corrects the XML. >> >>> so basically, I don¹t see many advantages for the SXE approach for >>> whiteboarding but I can see lots of disadvantages. I would seem to use that >>> a server based implementation for whiteboarding is far more flexible for the >>> types of sessions users really use whiteboarding for. >> That is unproven. I'm saying that it is possible to build a server-based implementation of SXE. I mis-spoke by conflating your criticisms of SXE with your criticisms of non-server-mode SXE. > no its not. we have been using a server based component for a year and half > with very good success. > > the SXE hasn't been proven to work for complex whiteboarding. our approach > has. btw, where is a current working implementation of SXE or SXE based > whiteboarding? There is no implementation yet of server-mode SXE as far as I know. All implementations are client-mode so far. Joonas is going to update the SXE proposal to more fully document the server-mode approach. Once that is done we can continue this conversation. Until then all this discussion is pretty much moot. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
