On 4/27/07, Martin Aspeli <[EMAIL PROTECTED]> wrote:
I think the cleanest design would be:
- You have a generic object UUID facility
- You make a UUID for a feed when you create it, and store it in the feed
annotation
- You generate feed item UUIDs on the fly from a hash/concatenation of the
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
Derek Richardson-2 wrote:
>
> Benji York wrote:
>> Derek Richardson wrote:
>>> The specific case is uuids for atom feed entries. We have annotations
>>> representing feeds and I would like my uuid utility to be local to the
>>> feed annotation, thus recording and making available uuids only f
Derek Richardson wrote:
The specific case is uuids for atom feed entries. We have annotations
representing feeds and I would like my uuid utility to be local to the
feed annotation, thus recording and making available uuids only for
entries in that feed.
How about a multi-adapter from content
I would like to create utility instances that are local to annotation
instances. Each utility would be valid only within the scope of the
related annotation.
The specific case is uuids for atom feed entries. We have annotations
representing feeds and I would like my uuid utility to be local to
