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 | [EMAIL PROTECTED] | http://blog.ianbicking.org
_______________________________________________
Sugar mailing list
[email protected]
http://mailman.laptop.org/mailman/listinfo/sugar
