[Telepathy] New channel request/announcement/dispatch interfaces

[Simon McVittie]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 14 Apr 2008 at 12:31:59 -0700, Ted Gould wrote:
> On Fri, 2008-04-11 at 12:41 +0100, Alban Crequy wrote:
> > Le Thu, 10 Apr 2008 13:18:14 -0700,
> > Ted Gould <ted at ubuntu.com> a écrit :
> > > Plus the low level protocol could be SXE on Jabber, or
> > > something else on another transport (is there other IM besides
> > > Jabber? ;) )
> > 
> > Abicollab has already a protocol for collaborative edition and I am not
> > sure it fits in the SXE protocol: Abicollab has its own way to handle
> > undo and collision due to internet lag.
> > http://www.gnomejournal.org/article/31/gocollab----peer-to-peer-document-collaboration

The correct mapping of AbiCollab into Telepathy would probably be to use
a stream tube (a TCP-ish socket tunnelled through implementation-specific
protocols), since their model is fundamentally that one participant opens a
TCP socket and everyone else connects to it. At the moment, the Write activity
on the OLPC uses D-Bus tubes, but that's only because we implemented those
first.

> > 
> > SXE is limited to editing XML and cannot be used for collaborative
> > edition of non-XML documents or for protocols that are not
> > collaborative edition of documents (e.g. the gtetrinet protocol, or
> > the openarena protocol).
> 
> Sure, I understand.  SXE has the same issues that Abicollab, and I
> actually like the protocol we used in Inkboard better than both of them.
> But, my goal there is to help SXE get the positive features of Inkboard
> and move to something standard.  The more we can get to a standard and
> abstract it out, the less code everyone has to maintain.

I haven't looked at SXE in detail, but I'd be slightly reluctant to have
a Telepathy API that was inextricably tied to a proto-XEP that's not
even at Draft status yet! :-)

> > > I guess, in a nutshell, what I'd like is two things:
> > > 
> > > - A way to register an application to receive particular MIME types
> > 
> > Instead of registering particular MIME types, I would register
> > particular protocol. For example, the gtetrinet protocol or the
> > abicollab protocol. We may have different protocol for ODT
> > collaborative edition with different ways to resolve collision due
> > internet lag (locking, merge).
> 
> I think if people want to have a custom protocol, they can use something
> like tubes which is very generic.  But, if they want to have an easy way
> to support synchronized editing of XML like documents they could use a
> Telepathy interface that is higher level and requires them to implement
> less code.

We can only do this if we can have a description of the operations supported
by SXE which is (at least theoretically) decoupled from XMPP - so it
could be implemented using any extensible protocol, for instance SIP.

> > > - A separate DBUS interface on protocol handlers that is a higher
> > > level document sync interface.
> > 
> > I don't understand your second point.
> 
> More of an implementation detail.  I was thinking that a way to
> implement it would be to have an interface for shared documents.  So a
> particular protocol could support
> "org.freedesktop.Telepathy.Connection.Interface.Presence" and
> "org.freedesktop.Telepathy.Connection.Interface.SharedDocuments".

One channel of type org.freedesktop.Telepathy.Channel.Type.SharedXMLDocument
per document, surely?

> What I'd really like to see is Telepathy adopt and encourage a standard
> across-the-wire protocol.  If we have a bunch of application invent
> their own protocols we'll end up with a mishmash of different features
> and availability across all of them.  This won't go towards helping the
> user experience any as they won't know what to expect of the various
> collaboration features.

This might be a worthy goal. On the other hand, applications can and do
have differing requirements - what's appropriate for collaborative word
processing (AbiCollab etc.) might not be appropriate for collaborative
spreadsheet editing (imagine Gnumeric gained similar functionality). Has
SXE been prototyped and tried out with multiple content types?

This is something we ran into in the design of D-Bus Tubes on the OLPC.
We implemented a relatively lightweight message-passing system (D-Bus
tunneled through XMPP in the obvious way, in fact!), whereas some of the
OLPC developers seemed to expect that we would have constructed a fully
generic shared-state abstraction.

However, a fully generic shared-state is "expensive" (you have to use
two-phase commits to change anything, and you'll run into difficulties
if one of the peers becomes unresponsive - always possible on an
unreliable Internet link). If all you actually wanted
was message passing, it's a ridiculous overkill.

If all you want to interoperate with are Telepathy clients, Tubes can
operate in three modes:

- - stream tubes (similar to TCP) - one participant "offers a service"
  (listens on a socket) and other participants may connect to it;
  the same ordering/reliability guarantees as TCP. Used by gtetrinet and
  VNC, should be used by AbiCollab

- - datagram tubes (not yet implemented, similar to UDP) - same
  client/server model as stream tubes, but unreliable and fast. Could be used
  by the various open-source Quake engines

- - D-Bus tubes (similar to D-Bus) - message-passing using the D-Bus wire
  protocol, borrowing conventions about methods/signals/errors/good API
  design from D-Bus. Messages are reliable (retransmitted if necessary).
  Messages from a given participant are totally ordered, but only
  causal ordering is guaranteed in the way that messages from multiple
  participants will interleave. Used by most OLPC activities

If you want to interoperate with non-Telepathy clients, then either we
have to write protocols and ask people to interoperate with us (at which
point we might as well use a general message-passing system like Tubes, tbh),
or we're stuck with whatever protocols other people use (and will
probably have to do a Telepathy interface per use-case, rather than
a generic interface like Tubes).

For instance, if we implement a "shared whiteboard" using SXE while the
rest of the world is using (from a quick Google search)
http://www.xmpp.org/extensions/inbox/whiteboard2.html or
http://coccinella.sourceforge.net/docs/MemoSVG_XMPP.txt, it's not clear
to me that that helps anyone...

    Simon
-----BEGIN PGP SIGNATURE-----

iD8DBQFIBJDbWSc8zVUw7HYRAm/oAKDELY1KRjEx0UuuE2iDfl9mXlaM5wCgs/vo
8Xnz6CvOpcrC5wEYdW/7TI4=
=Gqqv
-----END PGP SIGNATURE-----