Andrew Clunis wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, Dec 18, 2006 at 12:43:41PM -0600, Ian Bicking wrote:
Ah, directories, filenames, and compound documents -- the big open
issues in the document store / journal.
I had a terrible, sinful idea here: how about making a directory with
some contents a discrete document type in the docstore/journal?
That way, certain things that don't lend themselves on a granular level
to journal storage (like, for instance, source trees) will still work,
but still be ultimately managed by the journal.
Well, that opens up the question of whether the container is opaque to
the journal or not.
If it is opaque... well, then it's just a big bundle of data. You could
toss a zip file in there, for instance (and at least for Python source
thats a reasonable format). But I don't think that's what we want to do.
The files are actually an integration layer of sorts between activities.
For instance, an image file used in an activity could come from a
separate drawing activity. How do you import it into the activity
bundle? Can you continue to edit it after its been imported? Well,
that's probably not hard if the container isn't opaque, which is
probably what everyone has in mind.
Another thing I was discussing some with SJ was the idea that any
document/object/resource could also serve as a container. This is
rather contrary to how filesystems work, but compatible with the web and
potentially the journal. Actually it fits into the journal fairly well,
as it also introduces a type to the container. Typical directories all
look the same; there's no content or file type associated with them. In
the context of the Journal a simple directory would be an abstract
container object.
But if containers were typed objects then you could have a distinct
Activity container, Crossmark document (which can contain images),
Browser session (which contains more specific events like browser
history), and so on. Each clearly is distinct from a user point of
view, and in many contexts will be effectively opaque (e.g., the
Crossmark editor might treat images as if they are actually embedded in
the document, even though Crossmark itself doesn't allow inlining of
images).
An option at that point is whether objects are linked or truly
contained, or perhaps both. Typically an object knows what its
container is, and for instance when the container is deleted the
subobjects are deleted. But if you make an image, then use it in an
activity, what happens? Is the image copied, and then the copy
contained? Is the image simply linked? Is the image moved? When you
edit the image later, is the image in the activity updated?
Then there's serialization, which is where the content repository
becomes involved. But I think we should think of that as explicit
serialization -- if two objects are linked, then they both have to be
serialized and uploaded, and their references have to be resolved
somehow to point to the new locations.
Then there's the question of where the content actually is located.
Does everything go in the document store? If so, in this case we either
have to hack in Python to read out of the document store, or we have to
have something like a checkout of the files. Alternately, the journal
(or even the document store) could be aware of the filesystem content.
This is somewhat similar to being aware of remote content, which also is
not directly in the document store.
--
Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org
_______________________________________________
Sugar mailing list
[email protected]
http://mailman.laptop.org/mailman/listinfo/sugar
