Just found this in the mail attached below:
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.
So we can count on using files for some of our storage needs.
- Bert -
Anfang der weitergeleiteten E-Mail:
Von: Ivan Krstić krstic@solarsail.hcs.harvard.edu Datum: 11. Oktober 2006 12:08:17 MESZ An: Ian Bicking ianb@colorstudy.com, sugar@laptop.org, dcbw@redhat.com Betreff: Re: [sugar] Content types
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@solarsail.hcs.harvard.edu | GPG: 0x147C722D _______________________________________________ Sugar mailing list Sugar@laptop.org http://mailman.laptop.org/mailman/listinfo/sugar