[sugar] Squeak / Etoys RPMs

[Dan Williams]

On Tue, 2006-10-10 at 14:51 -0400, Owen Williams wrote:
> On Tue, 2006-10-10 at 14:06 -0400, Dan Williams wrote:
> > On Tue, 2006-10-10 at 13:55 -0400, Owen Williams wrote:
> > > On Tue, 2006-10-10 at 13:09 -0400, Dan Williams wrote:
> > > 
> > > 
> > > > 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.
> > > 
> > > What about files that were not created on an OLPC, such as oggs,
> > > theoras, pdfs, or other media?  I'm writing an RSS reader for OLPC, and
> > > it downloads files contained in RSS enclosures.  If there's no mimetype
> > > database on the system, it seems to cut olpc off from the rest of the
> > > world's content.
> > 
> > Maybe I am not understanding this.  What do you need a mime database for
> > with RSS?  Where do you plan to store the RSS enclosures in the flash,
> > and how do you plan to display enclosures that have been previously
> > "saved", whatever that means?
> > 
> > Dan
> 
> Podcasts and video blogs both use RSS as their distribution mechanism.
> Audio and video files are enclosed in RSS, and then the "pod-catcher"
> program downloads these files and saves them for later playback.  
> 
> The current, gnome desktop-specific workflow, is that enclosures are
> saved in ~/.penguintv/media, and when they are opened by my software, I
> query gnome-vfs to find out what program should be used to open the
> file.  Usually this is a media player like Totem, but if the enclosure
> is a pdf, for instance, it launches evince, acroread, or whatever the
> user has configured.
> 
> In the OLPC use-case, I was envisioning that a teacher could distribute
> class materials -- textbook chapters, homework assignments, etc -- by
> RSS, and then the students could open the files at home.  The idea was
> that files would indeed be saved on the flash.  Any materials developed
> with OLPC software would have the activity association you mentioned,
> but more standard formats will need to be viewed by an appropriate
> activity, like a music player, video player, or document viewer.

We want to have a strong association between the activity that _created_
the thing, and the thing itself.  That's completely independent from
what "file type" the thing is, whatever that means (which is mostly
unimportant).  Yes, this is like Type & Creator codes from classic Mac
OS.  Why did they fail?  Because you had to interop with DOS & Windows.
WE DON'T, at least our environments are more homogeneous and the onus is
on the outside world to provide information in a format that works on
the OLPC.

What does this system give us that simple file types based on extension
and/or magic don't?  It lets use _strongly_ link a resource with the
activity which it was created, and therefore use that activity every
time you edit or view that resource.

So, in your case with RSS, ideally you can provide an activity type
within the enclosure, or some other way, which the system would
(validate and then) use as the default activity to open that object.
The object also has a "resource type" (ie, file type/mime type) which is
determined from extension and/or magic.  Therefore, one or more
activities which recognize that type can open the resource, but only one
activity edits/views it by default.

The problems come when we grab random data, like Ian said.  In this
case, say over HTTP, we are given a mime type, and we may/may not use
that mime type.  The file is 'typed' from extension and/or magic, and
assigned a default activity type.

The point is to have the strong mapping between the thing, and the
activity which created it or should edit/view it.  The journal will
always launch the item using the default activity type, _not_ the "file
type".  The RSS reader will always run the activity specified by the
thing's default activity type.  We'll have to provide services to do the
mappings.

Dan