[sugar] Develop Activity

[Andrew Clunis]

-----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.

My rationale for this idea:
- - certain things would require huge amounts of hacking to support any
  other model for storing compound documents;
- - if we were to do that, we'd be basically changing something very
  fundamental.  does OLPC really have the resources to attempt that?  It
  also means that OLPC activity code might be even harder to port/run on
  other platforms, too.

Of course, even this method would leave a bunch of unanswered questions:
how would this fit into the version control/branching feature I
described for the Develop activity (in particular, I figure bazaar or
another dvcs gives us the features we need there, but sane integration
with the journal is a really hard issue).

PS. I hope the /journal stuff makes it to the HIG soon!  I'm
kind of flying blind and guessing wildly at what you folks are
intending.  Therefore, I take no responsibility if the stuff I wrote
above is a load of dingos' kidneys.
> 
> An activity in this sense is something like a compound document.  It's a 
> single entity with many pieces.  These pieces are all related to each 
> other.  The way these relations are traditionally represented is through 
> filenames.  (Many of the same issues apply to a compound HTML document, 
> which refers to things like images by filename as well)
> 
> Well, if it's more palatable to the people who dislike files, "filename" 
> isn't *strictly* what is required here.  It could also be called a 
> "resource name".  And indeed, we can hack around Python's imports fairly 
> easily to have it load things from the document store instead of reading 
> concrete directories and files (though this may or may not end up being 
> useful).  But we *can't* remove the idea of named resources.  You can do 
> that in Squeak because it's been built that way, but it's way too far 
> from any of the other programming environments to be reasonable.
> 
> This doesn't mean we need a global directory structure.  I think it does 
> mean we need two things:
> 
> * The idea of a bunch of resources collected together.  In the case of 
> an activity, that means some source code, some images, the .info file, 
> and whatever else.  We've already given this a name: an Activity Bundle. 
>  It's important for more than just Activities, but we don't have a name 
> or clear idea for what that larger concept is.
> 
> * The idea that, inside that bundle scope, things have names.  These 
> names might be "activity.info", or "mypackage/mymodule.py". 
> Traditionally / indicates hierarchy; but you can also just view them all 
> as string identifiers.  The string identifiers are important, of course 
> -- mypackage/mymodule.py maps to mypackage.mymodule in Python.  We can't 
> choose these identifiers randomly, these need to be explicit and 
> persistent identifiers created by the author.
> 
> In some cases we *can* create names.  For instance, if you have an HTML 
> page and an image (or a Crossmark document and an image), the name of 
> the image isn't that important.  But once it gets a name, the other 
> document will also get a reference to the name (e.g., in <image 
> filename>).  So the name has to be persistent, even as the resources are 
> moved around.  It can't be a hash, for instance, nor something that is 
> volatile when the bundle is moved around (as some resource-UUID 
> proposals use the UUID).  In that case the name is a kind of reference, 
> and we need to keep the integrity of that reference and the relation 
> between the resources, but the name of the reference is incidental. 
> It's just that not all names are incidental.
> 
> 
> -- 
> Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org
>

- --
Regards,
Andrew Clunis
 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFFh3T4ALkUMXSNow8RAl29AJ9LM7PqKM5g+1VEt4nd/KXp7sos1QCeMY3g
EY84u/M4O+kL5u+JBR2++XE=
=sdjW
-----END PGP SIGNATURE-----