[sugar] "Garden": A (currently hypothetical) Sugar library for sharing state between Activity participants
Marco Pesenti Gritti
Tue Nov 28 05:20:40 EST 2006
Andrew Clunis wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Hi dan!
> I was hoping I could get a hold of you.
> On Mon, Nov 27, 2006 at 10:35:22AM -0500, Dan Williams wrote:
>> On Mon, 2006-11-27 at 03:01 -0500, Andrew Clunis wrote:
>> One problem with this is that you can't depend on multicast only. You
>> have to deal with both multicast _and_ unicast. Because of the nature
>> of wireless networks, you may be on a different channel than the person
>> sitting next to you. It's unclear whether or not multicast will
>> actually be routed correctly everywhere, and multicast has other
>> reliability issues (ie, multicast frames are not retried/acked in the
>> 802.11 protocol level, they are just dropped much like UDP). So over
>> multicast, there needs to be some best-effort delivery protocol like the
>> MostlyReliablePipe implements. But the MRP protocol is really bad and
>> shouldn't be used.
> That's why I wanted to chat with you. I want to use whatever subsystem
> that Sugar will provide for the message passing, but it was my
> understanding that sugar.p2p sucks right now and will be refactored/
> replaced. I would be very interested in hearing about how it will look
> in the future.
Btw, I think we should try and tackle this for BTest-2. It's a bit of a
stopper for activities author to start using the mesh.
>> It's a good idea to start working on something like this. And remember
>> to keep it simple from the start and work out from there, otherwise it
>> may seem like a mountain to climb. Furthermore, it might be useful to
>> identify one or two use-cases to build the model around; pick an
>> activity or two that you would envision would use this library, and look
>> at everything the library does with respect to those activities (and the
>> kids using those activities!) needs and interactions.
> I'm going to start with Sketch. :)
> But there's a lot of architectural issues to get sorted first, as you
> said before.
Feel free to take the sketch code (which is currently in sugar/tests/)
and move it out to his own module when you start to work on this.
More information about the Sugar-devel