[sugar] Squeak / Etoys RPMs

[Ian Bicking]

Dan Williams wrote:
> 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.

My experience with OS 9 with computers on the internet was that the 
creator codes worked ok but not great on the computer itself (sometimes 
programs would become lost, and files wouldn't open), it integrated 
poorly with other Macs (again missing or inappropriate programs were 
associated with the file), and integrated really badly with the rest of 
the world.  It wasn't Windows/DOS integration that caused the problem so 
much, it just didn't work well for any integration.

That said, I expect we'll have extensible metadata on the resources, 
probably string key/values similar to HTTP or email headers.  So there 
could be "Last-Activity: ActivityName" associated with a resource, and 
that can be used to figure out how to open the resource.  Additionally 
an activity could probably query the information store for all resources 
that belong to it, and so forth.  If the resource was shared with other 
users that data might not be passed along (I don't know whether sender 
or receiver would filter it, or if it would be modified in some way to 
become advisory instead of authoritative).

Adding mime types to data is not hard, there's just no reason we 
shouldn't do it unless the data is truly completely private to the activity.

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

Enclosures in RSS look like this:

<item>... other metadata...
   <enclosure url="http://www.scripting.com/mp3s/weatherReportSuite.mp3"
    length="12216320" type="audio/mpeg" />
</item>

Note that types on the web are never determined by extension or magic, 
and we don't need to add extensions to our system either.  I don't see 
any reason why we should ever do that; that's a sign we've lost 
potentially useful metadata about the object.  For instance, there's no 
extension or magic way to distinguish RSS from other XML.  There's lots 
of formats that we can specialize through a mime type by saying that the 
type of the file isn't just, say, application/xml, text/plain, or 
application/zip, but that it's something more specific, like 
application/xml+rss, or text/x-olpc-wiki-markup, or 
application/x-media-bundle, or whatever we want.

There's good reasons RSS looks the way it does, why mime types exist and 
are used; these are things that aren't broken and don't need to be 
fixed.  You want control over how we *use* this data, and that's fine -- 
the great thing about data is that it's just there, you get to use it 
however you want.  Because we aren't planning to use just plain files 
there will be room to hang the information you need onto resources.


-- 
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org