From: Scott L. <sco...@ho...> - 2003-08-17 23:42:44
|
Hello, I think the JEP title "Collaborative XML Document Editing" is a telling one. It is good because it captures a lot of what we have been discussing. The unit of focus is an "XML document", and this implies a measure of extenibility to derivative specs such as SVG, MathML, etc. Also, "editing" is the core of the problem which subsumes questions about concurrency, canvas resolution schemes, and, inevitably, about essential architectural details (i.e. the location of the document). Furthermore, the title emphasizes the primay goal of achieving a way to "collaborate". This may be accomplished by using an IM protocol such as Jabber. (Let me be straightforward, and pardon me if I sound too blunt.) However, I see great potential in Convey which transcends the limitations of Instant Messaging, the primary one being that a central server is necessary. Writing a client for Jabber may be necessary for a wide variety of good reasons. However, I think that to have the design of Convey influenced and constrained by JSF and its guidelines may run counter to the fundamental reasons of why I am excited about this project. Its potential greatly appeals to me. What is its potential? Its potential to transact in XML rather than a specific grammar of XML (ie. SVG), as we discussed, increases its applicability. There is another potential which I want to highlight. I think there is a way to design Convey so that it is compatible with IM protocols like Jabber and also decentralized P-2-P protocols (which currently may have aspects that still problematic, but its promise is captivating). Convey has great potential to be adaptable in this way -- of not being limited to or dependent on a specific kind of collaborative technology. A Convey which works with Jabber may use only its basic requirements of sending, receiving, login, etc; no extensions would be necessary. It is client-heavy because it uses the server only to relay messages. All other tasks are its responsibility. But writing a JEP may be worthwhile for many reasons. However, in my thinking, the persuasive force of Convey resides outside of the Jabber world. Jabber, like expat and wxWindows, is an enabling component for Convey. The core of Convey, also in my thinking, and perhaps in yours too, is how it addresses concurrency issues to allow for collaborative editing of XML documents. I would like to hear your opinion on the friendly comments above. Scott >From: "Andy Ames" <ag...@sb...> >Reply-To: con...@li... >To: <con...@li...> >Subject: [convey-developers] JEP - Collaborative XML Document Editing >Date: Fri, 15 Aug 2003 12:18:21 -0700 > >Hey, guys. > >This is partly a summary of a discussion Ed and I had and partly a >collection of my own thoughts on the subject. > >I propose that we write a Jabber Enhacement Proposal (JEP), with the >assistance of the Jabber Software Foundation (JSF), titled "Collaborative >XML Document Editing." Following is a collection of information that might >be relevant in getting started with a set of requirements for the protocol. > >1) Service Discovery > >Ed and I discovered that collaboration support was intended in the Jabber >spec. There is a JEP called Service Discovery (JEP 0030), which is intended >to supersede Jabber Browsing (JEP 0011) and Agent Information (JEP 0094). > >Jabber Browsing and Agent Information describe a request/response method of >querying a Jabber server's supported capabilities, a conference room's >paramaters, and even the participants of a conference room. > >Service Discovery is a much more flexible implementation of this querying >process. To give you an idea of what the Service Discovery XML looks like, >the following is an example of querying a JID (server) for supported >features and other information. > >SEND: <iq type='get' > from='ro...@mo.../orchard' > to='plays.shakespeare.lit' > id='info1'> > <query xmlns='http://jabber.org/protocol/disco#info'/> > </iq> > >RECV: <iq type='result' > from='plays.shakespeare.lit' > to='ro...@mo.../orchard' > id='info1'> > <query xmlns='http://jabber.org/protocol/disco#info'> > <identity category='conference' > type='text' > name='Play-Specific Chatrooms'/> > <identity category='directory' > type='room' > name='Play-Specific Chatrooms'/> > <feature var='gc-1.0'/> > <feature var='http://jabber.org/protocol/muc'/> > <feature var='jabber:iq:register'/> > <feature var='jabber:iq:search'/> > <feature var='jabber:iq:time'/> > <feature var='jabber:iq:version'/> > </query> > </iq> > >If you go to the following link, you'll see tables with the existing >registered types that may be advertised by JIDs and their nodes. The page >is >titled "Parameters for Service Discovery." > >http://www.jabber.org/registrar/disco.html > >The thing to notice is that there are registered Collaboration categories >(editor and whiteboard) for multi-user collaboration. This category is >separate from the Conference categories (irc and text). > >2) Multi-User Text Editing (JEP 0058) > >http://www.jabber.org/jeps/jep-0058.html > >This JEP is a very simple protocol for multiple users editing a plain-text >document using the diff format. The actual text documents are stored on the >server. A Jabber client may query the server for editable text documents >using a protocol like Service Discovery, but it's not. The server responds >with a list of editable texts. > >The Jabber client may then choose to subscribe to one of them. This means >all diffs sent by other parties will be forwarded to our Jabber client. The >client may subscribe with read-only or read-write access. The Jabber client >may then be used to make edits of the text document. All other subscribed >users will immediately see the results. > >This JEP is experimental and is NOT a recommendation. The first problem >that >I see with it is that is uses none of the standard JEPs (Service Discovery >or Jabber Browsing) for querying editable texts. > >3) Whiteboarding JIG > >http://www.jabber.org/jeps/jep-0010.html > >JEPs are not only for Jabber protocol enhancements. They're also used for >informational purposes or to inspire the JSF to take some action. That's >what the "Whiteboarding JIG" is for. It is a call to create a Jabber >Interest Group (JIG) to develop a Whiteboarding protocol enhancement. It >outlines some basic requirements for the protocol and gives some direction >to the JIG. > >This JEP cannot be found in the list of JEPs because its status has been >changed to obsolete. I discuss this in the next section. > >4) Jabber Interest Groups (JIGs) > >The status of the "Whiteboarding JIG" has been change to Obsolete because >JIGs have produced very little in the several years since they were >created. >See "Streamlining the JIGs" (JEP 0019) for a description of the problem and >explanation of why the JIGs have been disbanded. > >http://www.jabber.org/jeps/jep-0019.html > >To summarize, the Jabber community wasn't large enough to warrant the >creation of 10 separate JIGs. Nearly all of the JEPs that have been >produced >since the advent of JIGs has not been by the JIGs. The JEPs have been >created by individuals or small ad-hoc groups from outside the >organization. > >They did leave in tact the Standards JIG because that is where most of the >discussion of JEPs that came from outside the JSF occurred. It is >incredibly >active. I suggest we all join the mailing list. > >http://mailman.jabber.org/listinfo/standards-jig/ > >5) Jabber Enhancement Proposals (JEPs) > >The basic idea is that small, outside groups will draft JEPs, then discuss >them on that mailing list. Then, the group will continue to rewrite the JEP >based on the feedback. This process continues until there is a certain >amount of acceptance of the JEP by the Standards JIG community. > >At that point, the JEP is submitted for formal review by the Jabber >Council. >This is where the JEP is voted on for acceptance. The following link shows >the results of this year's votes. > >http://www.jabber.org/council/tallies_02.html > >This link is a more formal description of the JEP process: > >http://www.jabber.org/jeps/submit.php > >I might add that many JEPs never make it to the Jabber Council for one >reason or another. Also, many JEPs start out as proprietary extensions to >the Jabber protocol using <x/> child elements of <message/> elements. > >It is common to have an experimental server implementation in use during >the >drafting of the JEP. > >In other words, we do not have to let the JEP process interfere with us >creating Convey. > >6) Jabberzilla > >http://jabberzilla.mozdev.org/ > >Jabberzilla is a web-based Jabber client that was built directly into the >Mozilla sidebar. Mozilla is the successor to Netscape. > >Whiteboarding functionality was just added to Jabberzilla almost a year >ago. >Check out the screenshots for December 2001, January 2002, and March 2002: > >http://jabberzilla.mozdev.org/screenshots/ > >Mozilla has an SVG rendering library built directly into it. So, all you >have to do is provide an SVG DOM or file, and Mozilla can render it to a >window. Jabberzilla uses this feature to draw the SVG. > >The problem is that the Mozilla team removed the SVG from recent builds, so >the Jabberzilla whiteboard only works with older builds of Mozilla. > >The whiteboard is strictly a whiteboard. Meaning, when a user draws >something, it stays. No one can edit what was drawn, not even the artist. >You can, of course, clear the whiteboard and use an eraser. This type of >whiteboarding is much easier to implement that collaborative document >editing because every drawn graphic is simply appended to the end of the >SVG >DOM tree. > >By looking at the SVG sent by Jabberzilla, it seems that he hasn't solved >the concurrency problem. So, like Convey Java, graphic messages may appear >in different orders for different users. > >7) Coccinella > >http://hem.fyristorg.com/matben/ > >This is another Jabber-based whiteboard. This one is even more limited than >Jabberzilla. All you can do is draw the SVG content, then send the document >all-at-once to a recipient. Actually, it doesn't even use SVG. > >The weird thing is, it has MP3 and Quicktime support via a plugin >architecture. > >There is no concurrency issue with this client because of its all-at-once >nature. > >8) SVG Whiteboard > >http://oid.jabber.org/?oid=1025 > >This guy was attempting to solve the same problems as us. However, the link >to the project site is broken. The link above is imply a news announcement >he posted of a 0.1 release to the Jabber community. > >However, if you go to the domain where the broken link points at, you'll >find Mobile SVG and PDF document viewing: > >http://bitflash.com/ > >9) Whiteboarding Proposal > >http://www.protocol7.com/jabber/ > >This is the web page of the guy who originally submitted the Whiteboarding >JIG (JEP 0010). He has some example Jabber XML for the whiteboard and a >DTD. >It uses a subset of the SVG spec. > >It doesn't look like he has an implementation, though. > >Anyway, feel free to comment on any or all of these topics. If you both are >in agreement regarding a Collaborative XML Document Editing JEP, then the >next step is to focus in on requirements. > >Andy > > > >------------------------------------------------------- >This SF.Net email sponsored by: Free pre-built ASP.NET sites including >Data Reports, E-commerce, Portals, and Forums are available now. >Download today and enter to win an XBOX or Visual Studio .NET. >http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 >_______________________________________________ >convey-developers mailing list >con...@li... >https://lists.sourceforge.net/lists/listinfo/convey-developers _________________________________________________________________ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail |