RE: [convey-developers] JEP - Collaborative XML Document Editing

[Scott L. <sco...@ho...>]

Andy,

I really like your idea about an OOD for the client which may be suitable 
for the different possible implementations.  Not only will this approach 
motivate us, but also it may be technically advantageous.
With a convienent OOD we can rework/resuse the existing code without much 
hair-pulling.  I suspect that in going from a thick to thin Convey on 
Jabber, there would be significant code migration from the client to the 
server side.  Therefore, perhaps, a significant portion of the JEP would 
come from the OOD.

Yes, I agree, backing into corners should be avoided.

And speaking of corners, there's a bit of a catch, I believe, if a client is 
required to play the host (or pseudo-server) to address the problem of 
updating new participants with the XML document.  This would stray from a 
p-2-p capability which I hope would be inherent in the design.

An alternative would be to broadcast a chatroom (or in search of a chatroom) 
and accept the first response, and perhaps ignoring the rest..  Clients of 
different chatrooms would propagate the search request.  A desired client 
would respond with a preliminary handshake or immediately send off the whole 
document.  Even though this smells like p-2-p, it can be compatible within a 
Jabber framework of public/private messages.

A secondary effect of this method would be that it ensures the update is 
timely -- the new participant would be updated by the fastest client.  
However, it wouldn't completely solve potential problems which may arise 
during the initial start-up time.

One obvious problem may arise from the possibility that diff messages may be 
lost while waiting to obtain the whole XML document.   To compensate, a new 
participant may simply accept diff messages even before it has the complete 
document;  the resolution may be deferred.  Another approach may be to have 
a new participant send requests for the document  certain number of  times 
until it has concluded that the document has stabilized.

Anyway, just things to consider.

Scott


>From: "Andy Ames" <ag...@sb...>
>Reply-To: con...@li...
>To: <con...@li...>
>Subject: RE: [convey-developers] JEP - Collaborative XML Document Editing
>Date: Mon, 18 Aug 2003 19:59:31 -0700
>
>Scott,
>
>Okay. I'm starting to see all the various ways we can implement Convey. 
>I'll
>try to organize and summarize each implementation here, using terms that
>we've coined. My intention is that this will help us talk about Convey.
>
>1) Thick client Convey: this would be least dependent on a server and most
>autonomous of the implementations. I see two possible subcategories of a
>thick client implementation:
>
>a) Thick client Convey via Jabber (centralized p-2-p): this would use the
>existing Jabber infrastructure (client/server) for XML edits. However, 
>every
>client would store and manage its own
>copy of the XML doc. This scenario applies to both one-on-one chats and
>conference chats. This implementation also warrants our pseudo-server; 
>where
>one chat participant acts as the host in that it sends newly connecting
>members the current XML doc. Note that we don't need to develop or maintain
>our own server, so long as Jabber continues to remain active. If Jabber 
>goes
>inactive, then us or other companies will have to run a server.
>
>b) Thick client Convey (decentralized p-2-p): This is very similar in 
>nature
>and use cases as implementation (1a), it just doesn't use Jabber. There
>would still need to be hosts responsible for updating new participants of
>the existing XML doc. Clients would still store and manage a copy of the 
>XML
>doc.
>
>2) Thin client Convey (client/server): This requires us to develop and
>maintain a server. Again, I see two subcategories:
>
>a) Thin client via Jabber: Here, we write a Jabber server component plugin.
>This plugin will store the XML doc on a server and perform concurrency
>resolution. Of course, it can be configured by admins to require admin
>intervention upon concurrency conflicts.
>
>b) Thin client: Here, we write our own client/server protocol and develop a
>server. We could base the server on existing Jabber code--perhaps reuse the
>Jabber Session Manager (JSM) for client connections, and so on.
>
>So, we have a matrix of possibilities:
>
>       | Jabber | Custom
>------------------------
>Thick |   1a   |   1b
>------------------------
>Thin  |   2a   |   2b
>
>An interesting thing to note is that we also can have 1c, 2c, 1d, 2d...,
>depending on if we want to consider other technologies.
>
>Is this accurate?
>
>It is certainly feasible to implement the Convey client with all of these
>implementation scenarios. That way, we can ensure an OOD for the client 
>that
>wont back us into a corner. Not only that, it lets us all develop Convey,
>knowing that we will have an implementation that suits our own personal
>desires.
>
>Ed, can have his implementation for distance education. If he wants server
>side tracking of sessions and hours (as is common for a public education
>institution), then he can implement it as needed.
>
>Scott, you can have a decentralized p-2-p implementation.
>
>I can have an IM-centric implementation, complete with buddy lists and so
>on.
>
>What do you think?
>
>Andy
>
>-----Original Message-----
>From: con...@li...
>[mailto:con...@li...]On Behalf Of Scott
>Luan
>Sent: Monday, August 18, 2003 4:56 PM
>To: con...@li...
>Subject: RE: [convey-developers] JEP - Collaborative XML Document
>Editing
>
>
>Andy,
>
>Thanks for your response.
>
>Instead of "IM", a better phrase would be "centralized p-2-p" which is 
>based
>on the server-client architecture.  This stands in contrast to a
>"decentralized p-2-p" (or just plain p-2-p) for client-client 
>communication.
>
>The specific limitation for Convey on Jabber, as I was thinking, and as you
>pointed out, is not the actual XML format of the messages, but rather the
>server-client paradigm itself.  As you said, however, it may be adequate 
>for
>the expected use-cases.  .
>
>Collaboratively editing a shared set of data may be applicable to 
>situations
>in which the clients may be in an isolated LAN or may not want to be
>dependent on the reliability of a server.  I admit that this would
>probably not apply to most users of Convey as an e-learning and user
>collaboration tool. Perhaps, my interest in a thick-client on p-2-p is
>merely academic and relates to more exotic uses.
>
>Nevertheless, I suspect that adapting the thick-client Jabber version of
>Convey for some p-2-p protocol may require less rework than making Convey
>thinner.  But I agree with you that a thin-client version of Convey using a
>Jabber-extension may be well justified given the use-cases you provided.
>
>Scott
>
> >From: "Andy Ames" <ag...@sb...>
> >Reply-To: con...@li...
> >To: <con...@li...>
> >Subject: RE: [convey-developers] JEP - Collaborative XML Document Editing
> >Date: Sun, 17 Aug 2003 21:57:28 -0700
> >
> >Hi,
> >
> >Comments embedded below.
> >
> > > -----Original Message-----
> > > From: con...@li...
> > > [mailto:con...@li...]On Behalf Of 
>Scott
> > > Luan
> > > Sent: Sunday, August 17, 2003 4:13 PM
> > > To: con...@li...
> > > Subject: Re: [convey-developers] JEP - Collaborative XML Document
> > > Editing
> >
> > > I think the JEP title "Collaborative XML Document Editing" is a 
>telling
> >one.
> > >   It is good because it captures a lot of what we have been 
>discussing.
> >The
> > > unit of focus is an "XML document", and this implies a measure of
> > > extenibility to derivative specs such as SVG, MathML, etc.  Also,
> >"editing"
> > > is the core of the problem which subsumes questions about concurrency,
> > > canvas resolution schemes, and,
> > > inevitably, about essential architectural details (i.e. the location 
>of
> >the
> > > document).  Furthermore, the title emphasizes the primay goal of
> >achieving
> >a
> > > way to "collaborate".  This may be accomplished by using an  IM 
>protocol
> > > such as Jabber.
> >
> > > (Let me be straightforward, and pardon me if I sound too blunt.)
> >
> > > However, I see great potential in Convey which transcends the
> >limitations
> >of
> > > Instant Messaging, the primary one being that a central server is
> >necessary.
> > >   Writing a client for Jabber may be necessary for a wide variety of
> >good
> > > reasons.  However, I think that to have the design of Convey 
>influenced
> >and
> > > constrained by JSF and its guidelines may run counter to the 
>fundamental
> > > reasons of why I am excited about this project.  Its potential greatly
> > > appeals to me.
> >
> > > What is its potential?  Its potential to transact in XML rather than a
> > > specific grammar of XML (ie. SVG), as we discussed, increases its
> > > applicability.
> >
> >I agree completely. We should focus on an XML-centered data view. All
> >collaborative conversations consist of an XML document. All elements of 
>the
> >conversation are done in XML. This includes the history of changes to a
> >document, the document itself, and so on.
> >
> > > There is another potential which I want to highlight.  I think there 
>is
> >a
> > > way to design Convey so that it is compatible with IM protocols like
> >Jabber
> > > and also decentralized P-2-P protocols (which currently may have 
>aspects
> > > that still  problematic, but its promise is captivating).  Convey has
> >great
> > > potential to be adaptable in this way -- of not being limited to or
> > > dependent on a specific kind of collaborative technology.
> >
> >IMO, P-2-P is not important. Actually, it's not important to me because 
>of
> >the relative difficulty in solving the problems inherent with P-2-P. 
>These
> >may be the problems you alluded to (firewalls).
> >
> >This may be short-sighted of me, but I don't see any application of 
>Convey
> >or collaborative XML document editing that cannot be done in a
> >client/server
> >paradigm.
> >
> >The use cases that I focus on are 1) one-on-one tutoring through an 
>online
> >learning center, 2) company business communications and collaborations, 
>3)
> >group instruction, and 4) friend-to-friend collaborations.
> >
> >Each of these use cases can be solved without going P-2-P. Am I missing 
>any
> >important use cases?
> >
> > > A Convey which works with Jabber may use only its basic requirements 
>of
> > > sending, receiving, login, etc;  no extensions would be necessary.  It
> >is
> > > client-heavy because it uses the server only to relay messages.  All
> >other
> > > tasks are its responsibility.
> >
> >This should be our first implementation of Convey. The first 
>implementation
> >should require no modifications to a Jabber server for it to work. Like 
>you
> >said, client-heavy.
> >
> >However, the trend of internet tecnology is toward server-heavy from
> >client-heavy. This has been the trend ever since the internet boom began.
> >Most would agree that this trend is not going to change, now that 
>everyone
> >is going mobile.
> >
> >I would only want a client-heavy Convey as a stepping stone toward
> >server-heavy. I wouldn't want client-heavy as the desired implementation.
> >
> > > But writing a JEP may be worthwhile for many reasons.  However, in my
> > > thinking, the persuasive force of Convey resides outside of the Jabber
> > > world.  Jabber, like expat and wxWindows, is an enabling component for
> > > Convey.  The core of Convey, also in my thinking, and perhaps in yours
> >too,
> > > is how it addresses concurrency issues to allow for collaborative
> >editing
> >of
> > > XML documents.
> >
> >One thing I want to point out is that Jabber does not in any way limit 
>and
> >restrict the implementation of our messaging formats. Jabber is a meta
> >protocol. The design philosophy of Jabber was that it posed no 
>restrictions
> >on the nature of the XML data it transmits.
> >
> >There are Jabber extensions for all sorts of applications. One notable
> >example, is Jabber XML-RPC. One can write a Jabber client that automates 
>a
> >remote Component (DCOM, Corba, EJB).
> >
> >If we use Jabber, we have complete control over the format of the data we
> >transmit, as long as it's XML. That's why the call it _eXtensbile_
> >Messaging
> >and Presence Protocol (XMPP).
> >
> >Of course, if we want a server to step in and do anything, we need to 
>write
> >a custom Jabber component. If we stay client-heavy, we never need to do
> >this.
> >
> >As for a JEP, no one implements a JEP until it has gone through at least 
>a
> >year of peer review, except for the original authors. The reason I'd like
> >to
> >write one, is its the expected method of communicating with the Jabber
> >community our intentions, so that they can peer review our work.
> >
> >The JEP authors usually are the only ones implementing the JEP at first.
> >Then, once the JEP has been accepted, others may jump on the bandwagon 
>and
> >implement a Jabber client that supports whatever the JEP adds. But, they
> >don't have to. Just like Convey never has to have a buddy list or post
> >presence information.
> >
> >Another thing I want to point out, is that Jabber is NOT an IM system. I
> >have been referring to Jabber as an IM system in err. IM is just the most
> >common use it's put to. XML-RPC is justification for the validity that
> >Jabber is not only an IM system.
> >
> >Here's where I stand on the topic, if we a) decide to go Jabber, and b)
> >want
> >the community to peer review us, then we write a JEP to facilitate the 
>peer
> >review.
> >
> >OTOH, if we don't go Jabber, we must justify to ourselves the value of 
>this
> >choice. Currently, I do not see the justification since the design of
> >Jabber
> >was to provide a framework for doing what we're trying to do.
> >
> >To aid in this decision, we must define the requirements of the system we
> >want to design and implement. If Jabber falls short of these 
>requirements,
> >then we do not use it. Of course, I'm sure this won't be that simple.
> >Jabber
> >may meet all requirements but a few. If that's the case, then we can
> >consider a server extension.
> >
> >(BTW, we can choose to use the Jabber server and protocol, and decide we
> >don't care about interoperability with other Jabbers users and IM 
>systems.
> >In this case, we'd just be using Jabber as a springboard into our own
> >custom
> >implementation.)
> >
> >Andy
> >
> ><snip>
> >
> >
> >
> >-------------------------------------------------------
> >This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> >Data Reports, E-commerce, Portals, and Forums are available now.
> >Download today and enter to win an XBOX or Visual Studio .NET.
> >http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> >_______________________________________________
> >convey-developers mailing list
> >con...@li...
> >https://lists.sourceforge.net/lists/listinfo/convey-developers
>
>_________________________________________________________________
><b>Get MSN 8</b> and help protect your children with advanced parental
>controls.  http://join.msn.com/?page=features/parental
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>Data Reports, E-commerce, Portals, and Forums are available now.
>Download today and enter to win an XBOX or Visual Studio .NET.
>http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
>_______________________________________________
>convey-developers mailing list
>con...@li...
>https://lists.sourceforge.net/lists/listinfo/convey-developers
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>Data Reports, E-commerce, Portals, and Forums are available now.
>Download today and enter to win an XBOX or Visual Studio .NET.
>http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
>_______________________________________________
>convey-developers mailing list
>con...@li...
>https://lists.sourceforge.net/lists/listinfo/convey-developers

_________________________________________________________________
<b>Get MSN 8</b> and help protect your children with advanced parental 
controls.  http://join.msn.com/?page=features/parental