We have looked extensively at both PubSub (at Joe Hildebrand¹s suggestion)
and ReX and have found both lacking in several significant ways. You can
find our issues with pubsub in the mailing list logs from about 1.5-2 years
ago. Our comments on ReX are:
1. REX has no history; either absolute or relative. There is no way to
join an existing session and be brought up to speed. There is also no way a
user can be disconnected, reconnect, and request the last X events to
process.
2. REX has no user information. Without using IQ packets or some form of
identification, there is no accountability. No one knows who edited what.
3. REX has no concept of roles or permissioning.
4. REX has no concept of presentation. A session does not track a
"current" page or have a presenter leading participants through a session.
There is also no way to have a virtual "pointer" or other presentation
tools.
5. REX has no way to handle file transfers. If an external entity is
linked into the document, there's no protocol in place for the file transfer
to occur so other users can link the information.
6. REX has no way to logically order documents. REX can support multiple
documents, but there is no concept of "next" or "previous" documents.
7. REX has no way to delete a document entirely.
Whiteboards aren't fundamentally documents they are an interactive
experience. You need to able to do things like controlling which page and
layer other users are seeing, manipulate and leverage permission in unique
ways, manipulate SVG is specific ways to support pages and layers, support
user's pointer movements, etc.... If we try to treat a whiteboard as only a
document then the users are going to have a very unpleasant experience.
We have a working server (OpenFire) and client (TransVerse) implementations
that are available for people to play with at https://xmpp.je.jfcom.mil. We
also have a 2nd server implementation for Jabber XCP that is 90% complete -
just missing the database persistence part and that will be done in next
couple of weeks.
So instead of tanking a working proven protocol (we've tested it with 100+
concurrent users). Why don't we look at what we need to update to the
current specification to address some of the concerns.
The XMPP community really needs a whiteboarding specification now. If ReX is
delayed until late 2008/or 2009 then the XMPP will have missed a great
opportunity to leap ahead. As some of you are aware, XMPP is gaining ground
rapidly in DOD, NATO, USGOV, and other national governments. Getting
whiteboarding standardized quickly (especially before the SIP/SIMPLE folks
are able to do it) would really help put many of the proprietary and SIMPLE
systems to rest.
I fear that if we try to force whiteboarding into a yet to be designed,
developed, and tested XML shared editing approach then it will be years
before an implementation is available that people can use.
boyd
On 8/10/07 6:30 PM, "Peter Saint-Andre" <[EMAIL PROTECTED]> wrote:
> In its meeting on Wednesday, the XMPP Council declined [1] to accept the
> most recent SVG whiteboarding proposal [2] as a XEP. However, the
> Council appreciates the efforts of those who have worked on the
> technology underlying that specification, which may provide helpful
> experiential input to standards-track work in this domain.
>
> The sense of the Council is that it would be more productive in the long
> term to define a generic technology for shared XML editing, similar to a
> previous proposal [3]. Such a technology could be used for whiteboarding
> with SVG as in a previous proposal [4], but also for shared editing of
> other XML formats such as XHTML, Open Document Format (ODF), and Atom.
> Limiting the approach to SVG whiteboarding alone will not provide for
> re-use of the technology for other applications.
>
> One approach previously explored would be to use the W3C's Remote Events
> in XML (REX) technology. [5] Unfortunately, REX has some limitations
> that would limit its usefulness for shared XML editing over XMPP, and in
> any case is patent-encumbered [6] so could not be used in an XSF
> specification.
>
> The Council will take it as an action item to investigate shared XML
> editing technologies in greater depth. There are challenging issues of
> synchronization involved (which would have been partially addressed by
> REX), as well as proper layering of the solution so that we can build
> multiple applications on top of the editing technology. At its next
> meeting the Council will discuss approaches for solving these problems,
> which may involve assigning a team or individual to work on solutions
> (as we have done in the past, e.g. when Peter Millard was tasked with
> working on Publish-Subscribe).
>
> As always, feedback is welcome.
>
> /psa
>
> [1]
> http://www.jabber.org/muc-logs/[EMAIL PROTECTED]/2007-08-08.html#1
> 2:53:57
>
> [2] http://www.xmpp.org/extensions/inbox/whiteboard2.html
>
> [3] http://www.xmpp.org/extensions/inbox/sxde.html
>
> [4] http://www.xmpp.org/extensions/inbox/whiteboard.html
>
> [5] http://www.w3.org/TR/rex/
>
> [6] http://www.w3.org/News/2007#item170
>
