[sugar] Squeak / Etoys RPMs

[Dan Williams]

On Tue, 2006-10-10 at 13:09 -0400, Dan Williams wrote:
> 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.

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

- 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

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

Dan

> > >> 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
> 
> 
> 
> _______________________________________________
> Sugar mailing list
> Sugar at laptop.org
> http://mailman.laptop.org/mailman/listinfo/sugar