[Zope3-Users] Re: Utility Local to an Annotation?

[Derek Richardson]

Martin Aspeli wrote:
> 
> 
> Derek Richardson-2 wrote:
>> Yes, it does feel like I'm going about this the wrong way.
>>
>> a - The "feed" is actually just configuration metadata - whether the 
>> feed is enabled, whether it is recursive, what its display name is, etc. 
>> The actual feed document is not stored - it is simply rendered 
>> dynamically when requested, based on the metadata and the existent 
>> content items. The "feed" is an annotation on a container; at the 
>> current time, only folders are feeds and only contained files are feed 
>> items.
> 
> Okay, so the feed is really a view, which consults some annotations on a
> container and then recursively looks for objects in that container and
> constructs XML?

Yes.

>> b - In the Atom syndication format, UUIDs are necessary for two things. 
>> One, the overall feed has a UUID. This is easy - I'm storing them in a 
>> site-local named utility, indexed by the feed annotation object.
> 
> What do yuo mean "indexed by"?

Hand the utility a feed annotation, get back a uuid for the feed.

> Also, is this UUID not just another aspect of feed "metadata" and thus a
> candidate for the container annotation?

This was the original plan, but I was convinced to go with the more
generalized solution of a uuid utility. I guess I can cache it in the
container annotation, but that's an optimization and tangential to this
discussion.

>  Two, 
>> each entry in a feed has a UUID. A content item that is an entry (a 
>> file, in the current case) can, however, be in multiple feeds and needs 
>> a different UUID in each. Thus, I need to be able to look up UUIDs by 
>> the content object that will be rendered as a feed entry and look them 
>> up relative to the feed, rather than globally.
>>
> 
> That sounds to me like you want a composite UUID - a UUID utility gives each
> content item a UUID (which is not feed-specific, and stays in line with the
> general concept of a content object UUID). The one you put in the feed is
> the feed's UUID and the object's UUID are combined. You could possibly use
> some kind of hash if you needed to.

I considered this. I have a certain understanding of what I'm doing that
precludes the combinatorial UUID approach, but no one I talk to seems to
grasp it, so I think I will air it here so we can discuss it.

I am using RFC 4122 type 1 UUIDs. These are (practically) guaranteed
universally unique, as they are based on spatial (MAC address) and
temporal (CPU clock time) location. They have safeguards built in for
things like multiple CPUs and resetting the CPU clock.

However, they are only (practically) guaranteed universally unique if
*everyone* follows the same algorithm. If you use a different algorithm
for computing your UUIDs, then they may collide with my RFC 4122 ones,
since your algorithm doesn't compute them the same way and thus may use
different, supposedly unique information included in a different way
that results in the same UUID that I generate. Highly unlikely, but
vastly more likely than if we all follow the RFC. Thus, to me, part of
being a good citizen of the UUID world is to follow the exact RFC 4122
algorithm, so we can all get along without collisions.

There is no provision in RFC 4122 for combining two UUIDs to generate a
third, still unique, UUID. So, in my mind, combining two UUIDs, by
whatever method, results in a relative UID, not a UUID.

Granted, I live in a fantasy world where everyone plays by the same RFC
4122 rules. Still, it's a nice world and I want to do what I can to
encourage others to join me in it. So, I want to generate
strictly-compliant RFC 4122 UUIDs for use in my product (and my utility
makes it easy for others to use them elsewhere in Zope).

Thus I take the hard road, here. Is there a flaw in my reasoning?

>> c - I use the UUIDs only when rendering the feed, looking them up by 
>> object and sending them to the client embedded in the feed document. 
>> They are used for no other purpose.
> 
> Still, the concept of a UUID of a content object ought to be separate from
> and more general than your particular need for a feed item UUID.

Right, you can still assign one (or more) UUIDs to any content object, 
if you have a use case. My UUID is for the (dynamically generated) feed
item. The uuid utility is perfectly general and will let you assign a
UUID to any object that can be adapted to KeyReference (or perhaps, in
Zope2, any object that is usable by the intid utility).

>> So, my situation is that I've written my nifty uuid utility based on 
>> intid and I want to reuse it for feed entry UUID lookup. I can't use 
>> unnamed utilities because I may be accessing different uuid utilities 
>> for entries from the same place in the tree. It occurs to me that I 
>> could make them named utilities local to the object underlying the entry 
>> and look them up by the feed UUID they correspond to, but, in my 
>> understanding, that would require littering sites all over the place, 
>> which seems like bad citizenship. 
>>
> 
> It does. I would not do this at all.
> 
> I think the cleanest design would be:
> 
>  - You have a generic object UUID facility

I've got that part.

>  - You make a UUID for a feed when you create it, and store it in the feed
> annotation

That, as mentioned, seems like an optimization. Perhaps worthwhile, but
orthogonal to the issue here. Correct me if I'm wrong.

>  - You generate feed item UUIDs on the fly from a hash/concatenation of the
> feed UUID and the generic object UUID

Like I said, that is the easy route, which I rejected for the reason
given above. If someone convinces me I'm mistaken, then I'll be happy to
do this, as laziness is a virtue. ;)


Thanks for the detailed reply. I look forward to future installments of
this discussion. :)

Derek