[sugar] Content types

[Ivan Krstić]

Ian Bicking wrote:
> There's other aspects too.  Is the data versioned?  Some data should be.

The data store provides integration with the differential storage engine
which activities are free to use or not use, as makes sense for each
item they store.

> And there's a mime registration use case too -- you need a custom viewer
> to view application/xml+x-olpc-chat. 

Well, *maybe* you need a mime database, but it's for the case where the
common viewing app for a format is not the app that created the file.
So, for example, with the chat logs -- if you find the logs in the
journal, the journal can start the chat app's log viewer for you without
consulting a mime database, since it knows that the chat app created the
logs.

If you find the logs through a resource browser, it can do the same
since the logs have a tag indicating the originating application.

But without a configurable mime mapping, you can't use either of these
mechanisms to say "actually, chat logs are just text files, and I'd
rather open those up in vim".

> From what I
> know of the plan for the storage system, I think it should be possible
> to delegate areas of storage to activities.

This has been my plan. Activities get a limited, secure file area of
their own to do with as they please, and access to the document store
for actual documents. Most activities will use the file area for things
like config files, but some might elect to use it to keep their own
sqlite database or some such.

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

Yes, it would.

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

Fully agreed, although the security implications are non-trivial.

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

+1.

-- 
Ivan Krsti? <krstic at solarsail.hcs.harvard.edu> | GPG: 0x147C722D