Dan Williams wrote:
The metadata is the hard one. Currently there seems to be:
* An icon and a name (both internationalized)
* A routine to run when the activity is installed
This doesn't exist. What the 'exec' line says is the command to run to
launch the actual activity. We don't run anything on install.
OK, that's what I first thought, but for some reason I then got the
other impression.
The
activity should have everything it needs inside itself, and it should
not need to actively 'register' anything. If something like that needs
to happen, it needs to be the metadata.
OK, I think that's good.
* Maybe a routine to "run" the activity itself? Or perhaps this is
registered by the installation routine
See above.
* A deinstallation/deactivation routine
No :) Why is this necessary?
Only necessary if there was a setup routine.
This list seems much too short to me. A central registry of things like
mime handlers seems important. Do we allow for scripts to be run when
That's quite an open question. And what's the mime-handler registry
for? We don't have a desktop, so you don't really double-click to open
a random file.
You can download some random file. There has to be resources (whether
concrete files or not) *somewhere* on the system.
Otherwise we're stuck with the old Apple technique of recording the
program responsible for each file in the file itself. That was lame.
the machine starts up? Or do we allow for just some particular things
I don't think we want this right now. If we really need it (for
"services" or something else that's long-lived) we need to figure out
what the use-case is, and how we enable services without a UI (like the
presence service).
Listening for events was the particular case I was able to think of.
I'm thinking of code like this (from the dbus tutorial):
bus.add_signal_receiver(device_added_callback,
'DeviceAdded',
'org.freedesktop.Hal.Manager',
'org.freedesktop.Hal',
'/org/freedesktop/Hal/Manager')
Obviously you can't do exactly this invocation in a declarative manner,
but you can get close. I'm thinking of something where an activity
listens for a certain kind of event -- perhaps to log it, respond to it,
or if the event is a kind of non-directed request. The activity doesn't
actually have to be running until the event appears.
I don't currently have a use case for this, but it's hard to think of
things since there's so few activities (and hence interesting events)
out there.
-- for instance, a declaration that the activity should handle certain
events when they appear on the bus? Since a bundle implies that more
than one bundle providing the same (or equivalent) functionality can be
on the machine at one time, there has to be management above this. Does
Not really. Each activity has a 'service' name, which represents the
activity's DBus service. There can only be ONE active dbus service of a
certain name at any given time (that's not entirely true, but we want it
to be). If you try to install a bundle with the same 'service' name as
one that already exists, the install bits look at the 'activity_version'
key, which is an integer. If the one you're trying to install has a
greater version, it's installed. If it has the same or less, it's not
installed.
that management simply detect conflicts, and activate one bundle and not
the other? Or does every aspect where activities conflict get managed
separately? For instance, you could reasonably want two bundles to both
get an event. Or you can ask the user what the do when a certain file
type has to be handled.
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)
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.
The way I was thinking about it, if activities aren't singular then none
of these things are big problems.
And then there's a bunch of other issues when activities extend other
activities.
I also don't think we want this. The whole point of activity bundles
was to be self-contained. There will be a certain set of base Python
functionality installed on the OS along with Python, but beyond that,
you're on your own to package up the dependencies of your activity into
the activity itself. Same with a C/C++ activity. If you need some
random library that's not on the base system, you are responsible for
packaging that library up into your bundle and linking to it
appropriately (with RPATH or LD_LIBRARY_PATH or whatever).
Remember, we _may_ chroot into the activity's directory before executing
the activity. Activity bundles will _also_ be read-only. If the
activity needs to change anything, it must use the appropriate Sugar
profile path which is stored in the user's home directory.
These really are self-contained programs. Think of an activity bundle
like a Java JAR file or applet that must contain everything it needs,
aside from the standard VM on the machine.
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.
--
Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org
_______________________________________________
Sugar mailing list
[email protected]
http://mailman.laptop.org/mailman/listinfo/sugar
