[sugar] "Garden": A (currently hypothetical) Sugar library for sharing state between Activity participants

[Andrew Clunis]

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

Hi Ian,

thanks for the reply!

On Mon, Nov 27, 2006 at 02:52:04AM -0600, Ian Bicking wrote:
> Andrew Clunis wrote:
> >It seems to me that OLPC development would be much friendlier for
> >students, educators, and wizened geeks alike if Sugar provided a means
> >for an author to mesh-enable their Activities in an elegant,
> >non-obtrusive and declarative way, *without* the need for a traditional
> >client/server topology.  Right now it appears that sugar.p2p only
> >provides a very simple foundation, thus requiring authors to essentially
> >devise their own network protocol.
> >
> >"Garden", as I have termed the hypothetical system in the interim,
> >could be the answer to this problem.  It would be an amalgam, of sorts,
> >of a network object synchronisation system and the high-level Python
> >marshalling library sitting on top of it.
> >
> >Requirements:
> >
> >1) It needs to be easy for Python activity developers to write their
> >   activities without having to spend significant amounts of time
> >   devising an activity-specific network protocol;
> >
> >2) The syntax for using it should be as declarative and intuitive as
> >   possible;
> 
> I think the Python portion of this will be relatively easy to implement, 
> compared to the basic algorithm design.  Also, "declarative and 
> intuitive" can be a bit subjective and domain-specific.  All of which is 
> just to say that I think we can defer this portion of the design until 
> later, and focus on the language/runtime-neutral portion of this problem 
> space.

Yeah, it's becoming increasingly obvious that Garden really needs to
broken into two pieces; the actual sync protocol (itself sitting upon an
even simpler messaging API), and the language specific component that
does all the marshalling, event handling, and other sugar (no pun
intended).
> 
> >3) It should also at least be partially available (at least the network
> >   syncing component) to developers using a language other than Python; 
> >
> >Threat Model:
> >
> >Garden earns its name and threat model from the clever "Walled Garden"
> >metaphor mentioned in the OLPC Human Interface Guidelines.  The general
> >idea is that all participants enjoy equal and nearly absolute trust
> >within the context of an activity.  That said, there should be a clear
> >boundary between the activity context and the local personal context of
> >a user.  Everyone can draw and muck about in the soil, but you don't
> >want some other kid coming up and giving you a wet willy (read: explode
> >your laptop).
> 
> Additionally, just because you are sharing one object/document, you 
> don't want users to have access to all your objects/documents created by 
> the same activity.  The activity itself will probably have access to all 
> these.  So we need a stronger boundary than just the activity itself.

Actually, I thought that if a user was joined into several different
gruops using the same activity, each would get its own process,
completely discrete from the others.  That would mean that if one
manages to crash or get into an inconsistent state, only that instance
would go down.

Is it going to work differently?
> 
> Mostly this is okay if we don't exchange code.  Other possible holes are 
> application-specific (though still quite possible).

I discuss that later on in the "Best Practices" paragraph.

> 
> >A thread would probably be necessary to wait for new messages coming in
> >from the network, and a Lock for the entire shared object as well.
> 
> I imagine the message listener could also be part of the GTK event loop.

Hm, I hadn't thought of that.  Now, I may be a complete dummy and
perhaps sockets work differently under Python than I'm used to, but
wouldn't the read() call block until a message arrived?

I guess that will really depend on how the messaging API turns out.

> >Best Practices for an Activity Author:
> >
> >- - Never trust any data inside a shared object outside the scope of the
> >  Activity (be wary of things like filenames, turing-complete code such
> >  as scripts, data that you might pass into code other than your own,
> >  etc.);
> >
> >- - Make the rest of your Activity code as state-independent as possible,
> >  because for several reasons the library may replace the entire state
> >  of the shared object(s)
> >  (conflict rollbacks, joining a new activity, etc.).
> 
> This is difficult, because essentially you'll have to poll your object 
> to see if it changed.  Polling is a big no-no for OLPC.
> 
> So then you get a situation where you will have, I suppose, events and 
> listeners, with one kind of event: "updated".  Then the UI listens for 
> an event from the model object, and updates the UI based on that.  At 
> which point one wonders if the model object is needed at all, or if the 
> events are sufficient?

Hear Hear on that one. I had in fact assumed that an Observer pattern/event
model would be used here.  Polling is stupid, slow, expensive, and unreliable.
> 
> >Other Possible Features:
> >
> >- - A "private" mode, whereby setting up a symmetric session
> >  key by doing some sort of key negotiation via DH.  This feature, if it
> >  exists at all, should be made easy to disable because many jurisdictions
> >  in the world take a jaundiced eye to cryptography.
> 
> Aren't all shared objects private until other users are specifically 
> invited?
> 
> Potentially this framework could implement the UI around making shared 
> objects available/public, inviting users, etc.  It seems like a common 
> UI around this could be nice.

Sugar's Presence system does all that already. :D

> 
> >- - A "proxy" mode to allow someone to bring a friend in who is not on the
> >  local network but rather on the public Internet somewhere.
> >
> >This is a really hard problem, so I elected to post this brain-dump
> >instead of write any code.  There will almost certainly be many differing
> >opinions about how to go about doing this.
> >
> >Is my take on this utterly hare-brained or does it have some merit? :)
> 
> It's definitely important to consider this, so thanks for bringing the 
> topic up.  I think there's a lot of discussion yet to come around this ;)

My pleasure.
> 
> -- 
> Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFFa6LoALkUMXSNow8RAiBSAJ9tiDZ8Q3bicGxTiZI9WwSgnR8eIgCeL08h
D6Qz9d/ednD/PCGw+Sz1Qbk=
=1oP9
-----END PGP SIGNATURE-----