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

[Andy A. <ag...@sb...>]

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>