[Zope3-dev] Moving from custom indexed collection to Zope3...

[Steve Alexander]

Hi Mike,

I don't have the time to fully digest what you're saying here, but I'll 
try to point you to the right places so you can answer your questions.

>    * I would need to modify the ObjectHub object itself to use
>      something other than "location" for storing pointers to objects...
>      seems like I must be misunderstanding:
>          o Does ObjectHub actually just store paths, rather than ZODB
>            object identifiers?

Its purpose is to maintain a mapping of object hub id (hubId) to path 
location. It should maintain this mapping even when objects are deleted 
or moved.
Not all objects are registered with the object hub. Which objects are 
registered is a policy decision -- you need to write a component that 
registers the objects that are important to you.
The maintenance of the hubId<-->location mapping depends on appropriate 
ObjectEvents being published by your objects or the views / adapters on 
your objects.
The ObjectHub generates hubIds randomly. There is no notion of 
monotonicity. You could write your own subclass of the ObjectHub that 
generates ids monotonically.


>          o The object seems to be just a persistent version of a
>            multi-producer multi-consumer event dispatcher, is this a
>            good characterization?

(I assume you mean 'The object hub' rather than 'The object'.)

The object hub subscribes to the event service. It receives all events 
from the event service. It sends these events on to subscribers to the 
object hub. It also sends additional "hubevents" on to its subscribers. 
Hub events are triggered when the object hub receives ObjectEvents 
pertaining to objects that are registered, or when objects are 
registered and unregistered.

>          o It doesn't seem to have any "collection" semantics at all,
>            which leaves me wondering what object provides the semantics
>            (does anything, or is everything "namespace"-based (i.e.
>            Folder or similar dictionary-like collections with
>            requirements for unique indices))?

A folder needs to have unique names for its subobjects so that the 
subobjects can be traversed to.
Your objects need to be uniquely identified by a path, if you want them 
to be traversed to. If you have non-unique ids then it is not clear how 
you would traverse to a particular object.

The setObject() method of the IContainer interface allows a container to 
select an id for an object newly added to it.


>    * I would need to support the "app/index" package, though this
>      appears to be entirely Web-focused, so possibly not

The zope.app.index package isn't web-focused. It is zope3 focused. The 
zope.app.browser.index package is entirely web-focused.


>    * Add the textindex to the ObjectHub as a subscriber (looking at the
>      textindex code, it doesn't appear to have anything to do with the
>      ObjectHub as of yet? I gather it is supposed to be readily
>      reusable outside of Zope.)

The zope.textindex package is reusable outside of zope. Nothing in 
zope.app is meant to be reusable outside of zope. There's nothing to 
stop you trying though ;-)


> Having spent a few hours researching now, I'm coming to the conclusion 
> that trying to use ObjectHub for non-Zope index-attribute support just 
> isn't appropriate...

The ObjectHub is designed to be used as part of Zope 3 and the component 
architecture.

> my assumptions about the nature of ObjectHub were 
> incorrect.  I still haven't come up with what it is in Zope3 that does 
> provide indexed-attribute support.  I know about IndexedCatalog by Async 
> Open Source, but I had been under the impression that Zope included a 
> similar system.  That impression may have been wrong...

Can you explain what "indexed-attribute support" is?

Perhaps the Query service, due to land RSN, will help there.

--
Steve Alexander