From: Andy A. <ag...@sb...> - 2003-08-15 19:35:01
|
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 |