[sugar] activity sharing protocol

[Dan Williams]

On Mon, 2007-02-19 at 16:07 +0100, Marco Pesenti Gritti wrote:
> On Mon, 2007-02-19 at 14:10 +0000, Robert McQueen wrote:
> > Marco Pesenti Gritti wrote:
> > > I forgot an important question. Will all the communication have to go
> > > through tubes or we will allow activity authors to use just the presence
> > > service with their own communication stuff? (i.e. let the PS expose the
> > > buddies ip)
> > 
> > From my perspective, not really. It's important to us that in Telepathy
> > we provide the right primitives that it's very easy to get an existing
> > TCP/whatever app (consider VNC via Telepathy or somesuch) working over
> > tubes. This would probably take the form of being able to get the CM to
> > expose the tube as a localhost TCP socket or Unix socket, and providing
> > convenient API to represent this to your app, eg GIOChannels in Glib,
> > whatever. In the long run the connection manager is going to get far
> > more clever at eg NAT traversal and stuff than your app will be.
> > 
> > For people who are writing an activity from scratch, I'd far rather
> > provide higher-level contructs like D-Bus messages, even using the
> > Python bindings to just have method/signal invocations, rather than
> > people having to invent their own wire protocols and
> > marshalling/serialisation etc.
> 
> OK, we have been saying to activity authors that just getting ip/port
> from the presence service would have worked so far. I guess we need to
> reconsider.
> 
> I have two use cases in mind here:
> 
> 1 Abiword collaboration

Rob talked to them, it's not hard to rearchitect this bit.  But that's
just Abiword.

Realistically, if you're modifying your activity to talk to the
PresenceService and the data store, you can modify it to ask for the
local TCP socket that represents the connection to some other buddy.
You don't really need to know the buddy's IP address and port, you just
need to ask Telepathy to give you a local socket.  Telepathy will
transparently handle the communication and make sure the data gets where
it needs to go.  So the activity won't need to modify it's actual
data-transport code (since it's still a socket), but it would need to
modify it's connection setup code slightly, which it already has to do
to find out who to connect to via the PS.

> 2 Develop activity using bazaar for code sharing.

How are they doing that?  Execing bazar from python with somebody's IP
address?  I think in this case you just figure out from the PS what the
local address of the socket is, and then use "localhost:32521" or
something, and that logically represents the person on the other end
since Telepathy would handle the transport for you if you're using
Tubes.

The one thing this _doesn't_ do is give you the remote address, but you
can't trust the remote address already anyway.  In our case we may/may
not care quite as much about NAT traversal in the pure case, but I don't
think we can always guarantee that a buddy you see via the server is
somebody you can always open a TCP connection to.

Any existing activity/app that relies on direct TCP connections to
somebody else with a non-public IP is already broken in some cases, and
there's no reason to expect OLPC installations to be any better, really.
Obviously if you can see them on the mesh, then yes you can open a
socket.  But if you talk to them through a server, who knows.

Dan

> About 1 I suppose maybe making abi collab use telepathy could be a win
> for the desktop version too?;) 2 is more like a legacy issue...
> 
> I'd really like uwog and orospark to comment directly on this!
> 
> Marco
> 
> _______________________________________________
> Sugar mailing list
> Sugar at laptop.org
> http://mailman.laptop.org/mailman/listinfo/sugar