[sugar] Squeak / Etoys RPMs

[Dan Williams]

On Tue, 2006-10-10 at 11:00 -0500, Ian Bicking wrote:
> 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.

Lets think about this in terms of use-cases.

A child gets a file from somewhere.  It could be off the web, if we
allow downloads of random stuff off the web.  At least we should allow
saving pictures and chunks of text or something.  Anyway, when the child
grabs them, the activity saves them in the _activity's_ piece of the
data store.  Whether or not they are public is another question.

So how does the child put that picture into something they are writing?
(first we need to know how the wiki+javascript+wysiwyg editor bits deal
with pictures)  In any case, the writing bits need access to pictures in
the child's data store.

This is an interesting question; we can't necessarily allow every
activity to access the data store of every other activity.  If you've
marked something "private" and any activity can access that thing, it's
no longer private because some activity could just pipe the thing over a
network socket.

So there's likely some sort of explicit action.  The child moves the
picture onto the "clipboard" on the left side of the screen, and then,
while in the writing activity, drops it onto the thing they are writing.
The picture is now "public", but its still in the area of the data store
which is owned by the web browser activity.  I don't think we really
should have "disconnected" files, because then you need a file browser
or something, and we don't have one, nor do we want one.

But here's where file type stuff may be important.  The writing activity
needs to at least know what sort of thing is being dropped on it.  So we
likely need some way of identifying files based on their name & magic.
We probably don't want this duplicated in every activity.

So it's not really a question of having a 'default application' which is
used to open a specific mime type, it's about letting activities figure
out what type of file they are getting based on extension and/or magic.
There are some pretty big security implications with letting activities
register mime type handlers for which they are responsible.  We get into
the whole "I'm RealPlayer; do you want me to handle every media type on
your system and override your current preferences?" dialogs which just
suck.  We are not going to do that.

I vote we just don't use mime type handlers for opening files.
Remember, we're not starting from a desktop of discrete files which you
need to open.  Stuff in the journal will save what activity you last
worked on something with, and that's how it will know how to get back to
it.

> >> 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.

You might mean dbus activation, but that works the other way around.  If
you need to make a method call on a service, dbus will block you method
call and launch that service, which then responds.  But I don't think
that's what you're getting at.

I think this is something that doesn't exist yet, even in a normal
desktop environment on a wide scale.  But for example's sake, on the
OLPC platform, a small tool that listened for pictures coming out of the
camera and popped up something when you took a picture.  That's an
example.  And we don't yet have a mechanism to deal with that.

There are two ways to do this of course; (a) start a service on
boot/login that listens for the events, or (b) create a system service
(like Upstart, huh? :) ) that launches the appropriate utility when the
event happens.  If we do this, we have to be _really_ careful here about
what is allowed to be started, for what events, and how it displays
itself.  Big opportunity for spyware/trojans/annoying viruses, etc.  Our
strategy for system services needs to be pretty tight.

> 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)

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.

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.

> 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.

> The way I was thinking about it, if activities aren't singular then none 
> of these things are big problems.

But other big problems come up that I'm not sure we want to deal with.
It's a tradeoff between ease-of-development for the small userbase, and
making stuff simple and flawless for the 100% userbase.

> >> 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.

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.

Dan