Eben Eliason wrote: > Anyway, the subtler point here, just for the sake of stating it > outright, is that sending an object to someone and sharing that > activity with them are (as they should be) quite different actions. In > the former case, they just get the object, and can use it as the > starting point for their own modifications, with their own history. In > the latter case, they will wind up with an object with the same > tree_id (and even version_id, for that matter) as the person who > shared it.
If version_id is meant to be preserved across shared sessions, then: 1. If I join someone else's shared session after it has been created, then I might have version "1.1.1" but no previous version. If I join again later, I might also get "1.1.1.3.2", with a gap in my version history. 2. Even weirder, if two people produce new versions independently, they will both get the same version_id, despite being entirely distinct objects. I conclude that either (a) version_id`s cannot be preserved or (b) version_id`s must be selected so as to be unique (e.g. based on large random numbers). >> Ok. Maybe we need some new vocabulary like "read/write metadata" vs. >> "read-only metadata". Action<->Document references would have to live in >> "read-only" metadata, managed by the Datastore. > > That seems like a reasonable split, but I'm not sure it falls on the > same line as versioned/un-versioned. I agree; they are not the same.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
