|
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
|