[Telepathy] New channel request/announcement/dispatch interfaces

[Ted Gould]

On Tue, 2008-04-15 at 12:26 +0100, Simon McVittie wrote:
> On Mon, 14 Apr 2008 at 12:31:59 -0700, Ted Gould wrote:
> > 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 do understand that.  In some respects that gives us the opportunity to
make sure it works for us :)

I've been talking with Jabber folks about this, I do think that SXE is
probably the way things will be going on the Jabber side.  But,
specification bodies are their own beasts.

> > 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.

Yes, I think so too.  That is one thing that I do like about SXE,
because it's designed to work on generic XML documents most of the
operations are "generic tree structured document" operations.  I would
think that they they could work with anything you could represent as a
tree structure including file-system hierarchies, etc.

> > 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?

Yes.

> > 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?

I would say that they are surprising similar.  I know when I was
watching Martin's talk at LCA I kept thinking to myself "that's the same
problem we had with Inkboard."  I think that document based editors
(whether they be drawing programs or word processors) have largely the
same needs with things like undo, coherency and conflicts.  Obviously
programs like Quake have very different requirements.

I think that we can solve a class of problems with this, not all (I'm
not suggesting dropping tubes or anything crazy like that) and that this
set of problems should be solved at the Telepathy level.

> 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.

Yes, I think that this should be limited to document sharing.

> 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).

Yes, and I think there are still many use-cases for Tubes.  (/me really
wants GGZ over tubes)  I hope that maybe the most useful of these could
be abstracted in a similar way in the future, but today I'm pretty
focused on just document sharing.

> 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...

For sure, if those got standardized for whiteboarding that would make
interoperability with those protocols non-obvious.  I think that in many
ways if the interface was generic, it could probably encompass them
also.  I'm on the jabber-whiteboard mailing list discussing them and
even the Inkboard protocol is a proposal there that you didn't find :)
Personally, I believe that SXE is the more likely protocol to get
standardized as it is more generic and can work for several different
document types.  Though, as I said before, standards bodies are well...
standards bodies.


At the end of the day (or e-mail), where do you think this sits?  What
should happen next?  Is it worth my time to write up something similar
to SXE (more generic) as an additional Telepathy interface?

		--Ted