[sugar] activity sharing protocol

[Andrew Clunis]

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

On Mon, Feb 19, 2007 at 11:20:51AM -0500, Dan Williams wrote:
> 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)

I had been wondering about this for a while.

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

I actually haven't implemented any of this yet, as I've been waiting for
this spec to come out.

But this definitely answers my question: I can't get away with running
bazaar's server directly and assuming that all mesh buddies will be able
to address each other via IP.

So, it looks like I will need to find some way to have Bazaar use the
CM transport mechanism (probably Tubes).

I knew from the start that I would have to extend Bazaar to handle URIs
that point to mesh buddies, direct connection or no.  Do buddies have a
GUID or similar string I can use to persistently identify them over the
long term?

I talk about URIs in my Thursday posting.

This is probably a good opportunity for me to deal with another question
I have:  I want an XO to be able to host any branches the child created
with Develop, even when Develop is not running.  Running the standard
Bazaar "smart server" all the time is out of the question: memory is far
to precious.  So, I think an "activiation" model (inetd style) would be much
nicer: the server facility is only loaded on demand.  What's the best way to
have a persistent facility that an XO offers over the mesh that is only
activated when a mesh buddy requests it?

> 
> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFF2gGeALkUMXSNow8RAnF/AJ93+L1Bjuq+mXoayUT7l/gUcveQRgCgir6a
n0B8OCu96lyy3/QYDDEdoTM=
=Oq2y
-----END PGP SIGNATURE-----