[Standards] whiteboarding and shared editing
Fletcher, Boyd C. CIV US USJFCOM JFL J9935
Boyd.Fletcher at je.jfcom.mil
Tue Aug 14 01:35:37 UTC 2007
I guess my fundamental issue is that the council is making an architectural decision of using shared document editing without understanding the problem or even having read the xep being submitted as many folks admitted to not even reading it.
So if we are going to do this objectively then we need all solutions weighted against one another and not levy artificial requirements.
Perhaps Joonas can update us on his progress and Mats and Ian could publish a draft of their specs?
USJFCOM J9/SPAWAR SC SD
M: 757.535.8190 (GSM)
M: 757.771.7084 (BB)
Sent from my BlackBerry so please excuse my typos.
From: standards-bounces at xmpp.org <standards-bounces at xmpp.org>
To: XMPP Extension Discussion List <standards at xmpp.org>
Sent: Mon Aug 13 19:03:20 2007
Subject: Re: [Standards] whiteboarding and shared editing
Boyd Fletcher wrote:
> 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:
As mentioned in the message to which you replied, REX is off the table:
So the XSF cannot and shall not base any shared editing spec on REX.
Therefore I snip your comments on REX, since they are not relevant.
However, note that the "shared XML document editing" approach that
Joonas Govenius defined previously does NOT rely on REX:
Ian Paterson and I tried to talk him into using REX because it would be
a good re-use of W3C standards. This is in large measure what slowed up
his work on shared editing. But now that even the W3C has decided to
stop working on REX, we can go back to solving our own problems in our
own way rather than relying on closed, big-company consortiums like the W3C.
> 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.
When Joonas worked on whiteboarding in Psi for last year's Google Summer
of Code project, he made significant progress on these issues. So has
Ian Paterson in his work on whiteboarding in Chatterbox. So has Mats
Bengtsson in Coccinella. We have quite a bit of experience with
whiteboarding. The problem now is to come up with a common specification
that everyone can agree on. Rough consensus and all that.
I agree that there may be special factors to take into account at the
SVG layer. But the sense of the Council is that those features can be
built on top of a common shared editing layer. Also, it is not yet clear
that other shared editing applications (e.g., Open Data Format) lack
some of the same challenges. I don't think we're claiming that all XML
documents are the same, only that they have important commonalities,
which it would be good to investigate when building shared editing
Naturally if there are special requirements for SVG editing, those need
to be taken into account. The same goes for other XML formats.
> 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.
There are many working implementations of many different proprietary
To take an example: Jabber XCP, Openfire, and other servers all have
their own working implementations of shared groups. Yet at the recent
XMPP devcon we all sat down and discussed requirements, as a result of
which we settled on a MUC-based protocol that none of the servers use
(I'm in the process of writing up our discussions).
The question is not whether a protocol extension is implemented in a
particular codebase or whether it "works", but whether it addresses the
full set of requirements, whether it provides a basis for building
similar technologies, whether other developers can easily understand it
and implement it, whether it is consistent with the other protocols we
have developed, etc.
All of these issues need to be investigated. The whiteboarding extension
you and your team have submitted may provide useful input to the process
of deciding on a shared editing protocol that we can put on the
standards track. As I said in my previous message, that remains to be
investigated. The Council has yet to seriously delve into this domain
and may in the end decide to pursue an approach that is closer to what
you and your team submitted.
Running code does not mean that if someone has something running it
automatically deserves to be standardized.
> 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.
Note that the shared editing and whiteboarding protocols that were
previously submitted also worked and were proven in the Psi client. Yet
those protocols too were not accepted. It's not a question of "tanking"
a given protocol extension or dissing a given team. It's a question of
developing sustainable infrastructure.
> The XMPP community really needs a whiteboarding specification now.
I'm not sure that there is universal agreement on that. There are many
potential things we could work on. Whiteboarding -- or, as I prefer to
call it, shared editing with whiteboarding as one application of the
core shared editing technology -- is one example. It is an interesting
example, but not the only example.
And, by the way, the desire for a specification "now" is not necessarily
the right way to design good protocols or sustainable technologies.
We've gotten into trouble with that kind of short-sighted approach in
the past, and the Council is wary of doing so again.
> If ReX is
> delayed until late 2008/or 2009 then the XMPP will have missed a great
> opportunity to leap ahead.
As I mentioned in my previous message, REX is off the table.
> 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)
That is not really a threat. The important thing is to develop something
solid, not rush something to market based on the chimerical notion that
a competing technology may be developed soon.
> would really help put many of the proprietary and SIMPLE
> systems to rest.
We're not necessarily here to put anyone to rest. We're here to develop
solid, sustainable technologies. That said, I think we can do so in a
reasonable period of time once we set our sights on it.
> 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.
People can use Coccinella, Psi, Chatterbox, or Transverse today.
Unfortunately those clients won't interoperate. That's not necessarily
the end of the world, since whiteboarding is a rather specialized
feature. Perhaps it would be better to pursue these individual projects
than to push something forward that the Council and developer community
thinks is not ready for prime time.
As I mentioned in my previous message, the Council will take it as an
action item to get more actively involved in developing shared editing
technologies. Expect more on that front soon.
More information about the Standards