[sugar] Content types (was: Squeak / Etoys RPMs)

[Ian Bicking]

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

There's other aspects too.  Is the data versioned?  Some data should be. 
  Some really doesn't have to be.  Unversioned data probably can really 
be plain files kept in a private location, and largely opaque to the 
outside world.  (Still needs to be cleaned up when the activity is 
released, and we should probably be very explicit about when and why 
that happens -- we don't want to be asking users about whether it is 
safe to delete any of those files that they've never seen before.)

Versioned data that really belongs to the user and not the activity is 
more interesting.  The activity may be an authoring tool.  It may leave 
logs -- like a chat program leaving chat histories.  These histories are 
quite independent of the chat program.  I'd be inclined to save them as, 
say, application/xml+x-olpc-chat (assuming they were in some XML format).

And there's a mime registration use case too -- you need a custom viewer 
to view application/xml+x-olpc-chat.  In fact a custom viewer for such 
things sucks, but then maybe you want something that can convert 
x-olpc-chat into text/html.  And maybe something custom that converts 
the content into a format the search engine would prefer.  Probably 
single "this activity handles this mime type" registration isn't a good 
idea.  More like "this activity handles aspect X of this mime type". 
Where X can be edit, view, convert-to-html, convert-to-searchable, 
summarize, convert-to-atom, etc.  And in each case the "activity" 
doesn't handle that content, some aspect of the activity does (so 
probably multiple exec's).

Hmm... a case just occurred to me.  Some application uses an internal 
format to store user data, but also wants the data to be searchable, 
loggable, etc.  Why does it use an internal format?  Not quite sure... 
maybe because the "standard" format is really bulky, or slow to 
encode/decode, or the application has reason to keep it in a SQLite 
database (which isn't really any kind of document at all).  From what I 
know of the plan for the storage system, I think it should be possible 
to delegate areas of storage to activities.

When this activity is removed, I see two options: you lose all that 
data, or you export all that data into the main persistence system. 
Maybe this is just something that should be declared in the 
activity.info in such a way that the activity-remover can figure out 
this situation applies.  Or now that I think about it, I'm guessing the 
storage system will know that this activity-managed data exists and can 
query the user in that case.

OK, so all resolved ;)  But I'll leave the thought experiment in the 
email, if only to suggest there's lots of ways these pieces can all fit 
together.

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

Activities may also be able to provide access to resources that aren't 
hosted on the laptop.  For instance, the chat activity may be able to 
provide images of your buddies.

I prefer having the storage manager query activities, than have 
activities poke things into the storage manager.  Sometimes.  Sometimes 
the storage is a place for activities to communicate with each other 
(similar to the clipboard, but more structured and long-lived).  I think 
there's lots of use cases for both situations.

So when you are getting an image, I'd like to see that turn into an API 
request (over dbus or whatever) for images.  Of course, then you really 
want to pop up a nice image browser.  Does the API call do that?  Does a 
separate process pop up, ultimately responding to the dbus call after 
user interaction?  Can any activity pop up, or just the system storage 
manager?  And when you are done, do you get back a URI of some sort, or 
the actual data?

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

We need watermarks!  Haha, j/k.  I assume the storage manager would 
handle this issue.

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

Well, "file browser" implies a storage implementation, and an 
implementation we don't want to expose.  But surely we'll have a 
resource browser?

Content doesn't have a activity owner, it has a human owner.  Really, 
having an application own a file is just what Macs used to do, and it 
totally sucked.

I actually imagine many different browsers, not a single one.  An image 
browser.  An any-kind-of-content browser.  A history browser.  A 
privacy/purging browser.  A where'd-all-my-disk-space-go browser.  Just 
because there won't be a singular hierarchical view of the storage 
doesn't mean we should leave out views of the storage!

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

We really don't need to use names and magic to figure out file types. 
If we care about content types at all we should just use MIME types.

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

Of course the system manages that, and in a more restrictive way than 
Windows.  I think if we avoid the assumption that a single activity will 
control a single mime type, that we'll avoid some of this mess.

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

I think that using the last activity is a reasonable default.

(I'll respond to the rest of this in another email)


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