[sugar] Activity development (was: Squeak / Etoys RPMs)
Tue Oct 10 17:52:19 EDT 2006
(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
> 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
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
More information about the Sugar-devel