[sugar] Develop Activity

[Ian Bicking]

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 | ianb at colorstudy.com | http://blog.ianbicking.org