[sugar] Avoid duplicates in the bundle registry

[Jameson "Chema" Quinn]

Let me try to sketch out the plan understand and interpret it from
http://wiki.laptop.org/go/User:Mstone/Commentaries/Bundles_1. (episode 2 was
more about how to handle the files/bundles or objects/actions distinction,
which is farther off).

1. in the future, object ID will just be a hash of the non-human-readable
signing key for an activity.

1.a) this will not change over minor version changes. It may not change over
major version changes, or, if author intends bugfix releases of the old
version, it may deliberately change. If there is a discontinuity in
authorship (key lost) it must change.

1.a)1)when we have signatures, hash collisions will be assumed to be a
deliberate attack, and will just refuse to install.
b) for right now, we can just use object ID.

2. Within each object ID, there can be any number of versions simultaneously
installed.

2.a) just id/version is not unique, for instance if an activity is under
active development on that machine.

2.a)i) An idea of mine, not discussed yet: we actually could try to enforce
the idea that any two activities which match on {id,version,bool(has valid
signature)} are interchangeable - just silently use the first one seen for
bundles with a valid signature (release versions), and the last one seen for
b. without v.s. (development versions.

2.b)Even if we can get some combination of data (besides just hashing the
whole bundle) that is unique, or if we make a pre-signature approximation
that id/version is unique, there will still be a large potential for
clutter.

3. Which one to use?

3a) Each journal object will have metadata with all identifying data (id,
version, sig?, hash) of the last activity.

3b) For some activity ids, there will be (at most) one starred version.

3c) Journal objects will open by default with {own id, max(starred version,
own version)}, or if that is unavailable starred version, or if that is
unavailable latest version.

3d) Unstarred id's can still be grouped/collapsed in the activity list.

3d) imported objects will open by default with starred or latest version

4. Garbage collection of old installed versions (this patch)

4a) Any versions older than starred version are eligible for GC.

4b) Suggestion (not discussed): Grace period to notice broken features: When
starred version changes, garbage collection on that ID is frozen until the
new starred version has been used at least 3 times.

4c) Suggestion: Suggested updates: First time quitting a version newer than
starred version, ask user if they want to move the star.

4d) Suggestion: when you see a shared activity in the mesh, some UI hint to
show if it is newer/older/same version as your starred/latest version.
(also, see "imposing changelogs" in the discussion)

...

As an aside, I think that it is a mistake to impose integer versions. I
think that a general n-number versioning system, with a hyphen as a
separator (to avoid the 1.10 problem), but Glucose only understands the
ordering and makes no distinction between major and minor version. This
would support integers, major-minor, major-minor-bugfix, or other similar
systems, without imposing one.

Jameson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/sugar/attachments/20080610/e202b4c4/attachment.htm