[sugar] Activity development (was: Squeak / Etoys RPMs)

[Ian Bicking]

(Continuing my response...)

Dan Williams wrote:
[...clipping stuff about events, Upstart, etc which satisfies the case I 
was thinking about...]
>>> I don't see having multiple bundles providing the same services as
>>> necessary or wanted.  What was the use-case you were thinking of?
>> Mostly branching and decentralized development.  E.g., when a student 
>> wants to start experimenting with modifying an activity, they can branch 
>> it into a new activity (maybe with a new name) and start modifying it in 
>> place.  Branching in this case is just making a copy.  (Integer activity 
>> versions don't allow for branching without changing the name... I'm not 
>> sure what that does to things)
> 
> See, that's where it starts to get complicated :)  I think this is a
> tradeoff between ease-of-development and simplicity.  I think I'd tend
> towards the side of simplicity, because _everyone_ will benefit from
> that, but only some percentage of kids will benefit from the
> ease-of-development side of things.

My impression of how OLPC was going to be released (and please correct 
me if I'm wrong, as I'm inferring this from some vague things I've seen 
here and there) is that it's going to be released as more of a platform 
than a finished product.  That is, the software in the first release 
will provide just a small part of the overall potential of the laptops. 
  So ongoing development, especially development coming from outside of 
OLPC and generally decentralized development, is really important to the 
success of the system.  And not just in a democratic principled free 
software kind of success, but actual concrete success in making a useful 
tool.

> Perhaps we make it easy to archive an activity into a compressed
> Activity Bundle which you can store somewhere, and the install your own
> custom activity with the same service name, hack on it, and when you're
> done, you archive that and install the real copy.  Make it work without
> too much pain to the developer, but make it work flawlessly and simply
> for everyone.
> 
> I just don't think that engineering for this use-case (even though you
> and I directly benefit) is the right thing to do.  We need to make it
> foolproof and simple for the 100% use-case and I think having multiple
> bundles with the same service name just makes things complicated.  How
> do you display #1 and #2 in the UI?  Which one "owns" the icon in the
> launcher area?  When you join the activity, which one do you launch?
> We're certainly not going to put up a dialog asking which one to launch.
> Somewhat back to the mime-type issue too.

And then Dan wrote:
> A possible solution to this issue is to lay the pain at the feet of
> people who want to use multiple activities.  But anyway:
> 
> - We already know that the Activity Bundle spec says the installer can
> name the activity bundle directory an arbitrary name.  The installer
> somehow assigns a unique ID to the activity bundle.  This ID is
> local-system-unique and is only used internally.
> 
> - We append the AB spec with the addition of a 'vendor' tag or something
> 
> - Only if the 'vendor' and 'service' tag matches some activity already
> installed, does the version compare happen and one activity get deleted
> or not installed

+1.  We can also create some "clone this activity and mark yourself as 
the vendor" action.

> - If the 'vendor' and 'service' tag combo is different than anything on
> the system, the activity gets installed
> 
> - The _first_ activity with a unique (vendor, service) tuple is set as
> the default activity for that service type

First in what way?  First to have been installed?  Or last to have been 
installed?  This sounds arbitrary, which means non-repeatable between 
laptops and generally confusing.  I guess last to have been installed 
probably makes the most sense, though, since it is the most recent action.

> - If you want to change the default activity for a service type, you
> must go through some pain, be it some arcane UI bits, or whatever, but
> you can

This could probably just be part of the activity installation.  Maybe 
another means of installation that installs an activity without 
disabling similar activities.

Of course when someone has "org.laptop.Chat; vendor=olpc" installed, and 
some buddy has installed "org.laptop.Chat; vendor=piglatin_branch" (what 
purpose does the branch serve?  Purely to be funny.  Kids will happily 
install and even use silly things like that)... what happens then?  Does 
the user get queried if they want this "updated" activity?  If for 
whatever reason they install it, decide they don't like piglatin as much 
as their friend, and then want to revert, then what?  Perhaps in that 
case simply keeping a record of activities that have been installed (and 
why they were uninstalled) will be enough to make an easy UI for reverting.

> This would seem to work, since it allows more than one 'org.laptop.Chat'
> activity, for example, to work with any other activity that implements
> the org.laptop.Chat protocol (which in reality is just an Avahi service
> announcement with some key/value pairs).

I've noticed the service name and the interface name are almost always 
the same.  Would it be at all useful here if they weren't the same?

>> If they change the service name, then anything that communicated with 
>> that service name won't be able to attach to their new code.  And if 
>> they don't change the service name, everything will get hopelessly 
>> confused once they start distributing their modified code.
> 
> Right, that's the issue here, tying the service name to the network
> protocols.  But once you separate the two (and have more than one
> _local_ activity provide the same type of network service) things get
> quite complicated WRT which one you decide to use at various points.  I
> don't think we want to go there for G1.

For broadcasted signals there's no problem, right?  So if an activity is 
just listening for signals, not for directed messages, it's not a problem.

But sure, to really support more than one activity running at the same 
time it probably requires work on both the activity and anything that 
interfaces with the activity to allow for that possibility.


Another issue that has occurred to me is localization of activities.  I 
think I read the plan is not to distribute all localization data, just 
the needed data, right?  Also, I would imagine that updates and 
contributions of localization data are going to happen faster and in a 
more decentralized manner than software development.  It seems like 
localization should be handled specially in activities for these reasons.


>> In terms of motivation, I'm thinking about someone wanting to extend an 
>> activity they don't "own".  One way to extend it is to take ownership, 
>> i.e., fork.  If the upstream author had foreseen the particular 
>> extension that is desired, they might have exposed the necessary parts 
>> over dbus, which would be ideal.  I'm not sure what the limits of dbus 
>> are.  If you want to display something on an activity's canvas, it 
>> doesn't seem reasonable to do so over dbus, except in some constrained 
>> manner that is set up ahead of time.  And maybe that's sufficient.
> 
> Some discussion was brought up about how  much of a set of tools (like
> OLE) do we want to provide, and how to let other activities use those
> tools.  This is in direct conflict with my last mail about all-inclusive
> activities.  But I think the thought on this is, if enough activities
> start using a particular bit of functionality, then we need to look at
> including that functionality in the base OS images.

One way to allow common functionality to emerge is to look for 
opportunities to share data in activities, especially since activities 
at least start out as read-only after installation.

An activity might simply specify that some directories or files are 
possibly shareable.  For Python activities, you'd do that for each 
package.  As part of the build process you'd also give a checksum of 
some sort for that portion.  Then on installation if the system saw that 
an identical directory existed it could use symlinks or something to 
save space (of course fixing things up if one of the pieces was removed 
or modified).  Would this also save memory for shared libraries? 
Anyway, there'd still be reason to move things into the base system. 
And there'd still be reasons *not* to use things in the base system, if 
you didn't want to be effected by system updates.  But it might be 
useful, and it doesn't seem terribly hard to implement.  (Scanning for 
generally for opportunities to share files doesn't make much sense, but 
with specifically marked files it's easy enough to scan, and I think 
it's easy to identify what files/directories are likely to be found in 
multiple packages)

But that's for libraries.  I don't know much about OLE or other systems 
like it.  Does the embedded object run in-process?  It seems like a 
complex undertaking unless every activity is similarly privileged and 
there's some kind of common runtime model.  (Which there kind of is on 
the GTK level, but that most notably doesn't include EToys.)  Anyway, 
like I said, I don't know much about this aspect so I'm just speculating.


-- 
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org