[sugar] Squeak / Etoys RPMs

[Ian Bicking]

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 | ianb at colorstudy.com | http://blog.ianbicking.org