[Etoys] File storage

[Bert Freudenberg]

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 at solarsail.hcs.harvard.edu>
> Datum: 11. Oktober 2006 12:08:17 MESZ
> An: Ian Bicking <ianb at colorstudy.com>, sugar at laptop.org,  
> dcbw at 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 at solarsail.hcs.harvard.edu> | GPG: 0x147C722D
> _______________________________________________
> Sugar mailing list
> Sugar at laptop.org
> http://mailman.laptop.org/mailman/listinfo/sugar