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

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

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