[Telepathy] New channel request/announcement/dispatch interfaces

[Ted Gould]

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 :
> > On Thu, 2008-04-10 at 10:06 -0700, Ted Gould wrote:
> > > I like this idea.  I'm not sure if you're familiar with SXE by the
> > > Jabber folks, but I think it'd be an interesting spec to use as a
> > > model for how this stuff works.
> > 
> > Upon receiving this e-mail back, I realize that it's to vague to be
> > useful :)
> > 
> > What I find interesting in this approach is the idea that you can say
> > to someone that I've go a document like X that I would like to share
> > with you.  Which, doesn't really mean that you're both using the same
> > editor on either side of the pipe.
> 
> Indeed, what matters is that both side of the pipe use the same
> protocol.

Yes, and I'm suggesting that we can abstract that out.

> > So, while there is the initiation
> > aspect of sharing a document, there is also the receiving client that
> > needs to figure out what to do with it.
> > 
> > So, what I'd like to see is a system of registering different document
> > types similar to how MIME types are handled on the rest of the
> > desktop. In that way I'd get an icon in my notification area saying
> > "Bob would like to share a drawing with you, open in Inkscape?"
> > 
> > I think it also make sense to abstract out the publication aspect of
> > sending the document.  A command like "share an SVG document with
> > Jenny" would make it much easier to implement clients (which is a
> > good thing). 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
> 
> 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 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.

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


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.

		--Ted