4suite uuid.py Re: [Dev] additions to oid coinage problem page
paigen at heathen.com
Tue Apr 8 16:36:36 PDT 2003
petite_abeille at mac.com wrote:
> On Tuesday, Apr 8, 2003, at 01:07 Europe/Zurich, rys mccusker wrote:
> > I had originally been planning on using 24 unique IDs, with 16 bytes
> > for the repository ID, and 8 bytes for objects inside a repository.
> Why would you want to mangle object id and repository id? If you need
> more information about your object aside from its identifier (e.g. its
> entity, how to get to it, etc), this most likely doesn't belong to the
> oid itself.
Either I don't understand the semantics of object "ownership" and access,
or I don't understand your question.
If Chandler can view, add, or modify items from many repositories at
once, Chandler will obviously need to know where those items reside
so that changes can be monitored or delivered.
Looking over that last paragraph I feel an example is in order:
- I am at work running Chandler, but I am connected to my Chandler at home.
- I buy a book during lunch hour (shock! what a surprise!).
- I enter the book information into my CardCatalog application (in Chandler).
Note: CardCatalog resides in my home repository, I just have access at work.
Chandler must now deliver the book item to the repository at home.
Furthermore, if the ordered pair of [repository ID, object ID] is the
UUID Chandler uses, then object IDs can safely be incremented integers
and simplicity rules. Then you just need to find a way to generate
good 16 byte UUIDs for the repository and don't worry about performance.
Having both a repository ID and an object ID, together, as a UUID has
precedent and is good design. Together does not mean mangled, as long
as you can still extract one or the other.
More information about the Dev