(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 | [EMAIL PROTECTED] | http://blog.ianbicking.org
_______________________________________________
Sugar mailing list
[email protected]
http://mailman.laptop.org/mailman/listinfo/sugar
