Peter, 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? . boyd Boyd Fletcher USJFCOM J9/SPAWAR SC SD M: 757.535.8190 (GSM) M: 757.771.7084 (BB) -------------------------- Sent from my BlackBerry so please excuse my typos. -----Original Message----- From: [EMAIL PROTECTED] <[EMAIL PROTECTED]> To: XMPP Extension Discussion List <standards@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: http://mail.jabber.org/pipermail/standards/2007-August/016372.html See also: http://www.w3.org/News/2007#item170 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: http://www.xmpp.org/extensions/inbox/sxde.html 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 technologies. 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 XMPP extensions. 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. Peter
