[Zope3-dev] ObjectHub: Kill the plugins!

[Steve Alexander]

Gary Poster wrote:
> I haven't had much time to write this out, so let me be brief, and
> expand as requested later:
> 
> We have now, in this neck of the service manager woods, an EventService
> and an ObjectHub (now also a service; client of the Event Service).  

Will you be able to check this into CVS soon?


> In addition, I propose
> 
>  * a MetadataService (client of the object hub; takes a hubId and
> returns a dict of whatever metadata we've collected about that object;
> this collection mechanism being presumably via an adapter, i.e. a more
> sophisticated and non-pseudocode version of (given hubid)
>  myObj = ObjectHub.getObject(hubid)
>  MetaDataService.myIOBTree[hubId] = getAdapter(myObj, ICachedMetadata)()
> where the called adapter returns the desired dict of info gathered from
> myObj),
> 
>  * an IndexService (client again of the object hub, and perhaps to a
> lesser degree of the MetadataService, that accepts TBD (To Be
> Determined) query objects, as discussed somewhere or another on the
> wiki, and returns TBD query results; contains addable indexes), 
> 
>  * and various query utilities (clients of the IndexService that each
> take a given variety of query--SQL-like, form-like, etc.-- and translate
> them into the ever-popular TBD query objects, which it passes to the
> IndexService to then return that result to the caller.

Ewww... too many services!

For me, these all come under the heading of "QueryService".
There are many advantages to having metadata, indexing and querying 
handled as plugins inside the same service. You can build a range of 
queries out of simple reusable parts, rather than have monolithic 
"indexes". You can also make the facilities of external indexing 
systems, such as Lucene or MySQL, available as a group of related 
plugins to provide such metadata, indexing and normalisation services, 
which can be used in combination with other sources of data.

There are also advantages to using a single service of collaborating 
plugins when you want to handle cascading deletes/renames -- when you 
delete or rename a folder, you can send just one event out to the 
object-hub, and the single HubId event sent to a plugin that knows about 
containment. This plugin can notify the other objecthub subscribers of 
the new location (or deletion) of all registered objects that are 
transitively contained within that folder.


Of course, such a plugin-oriented query service does not preclude having 
specific other services for indexes and metadata.



> In the previous conception of the object hub, most or all of these
> things would have been floating around in the object hub somewhere.  As
> I explained in the first email in the "Kill the plugins!" thread, there
> was a reason for this, but I think that reason is gone.  We have the
> infrastructure to put these in placeful services and in placeful
> utilities, and that's what I think makes the most sense.

I disagree, for the reasons mentioned above. I do agree that removing 
plugins from the objecthub is a good idea. I still think that a Query 
service that uses plugins is a very good thing.

I have a design for the Query service, and Query objects, and 
collaborating plugins. I discussed these at length with people at the 
EuroPython conference.

As soon as you check in your latest ObjectHub work, I'd like to start 
work on the Query service. I think I need to see the current state of 
the ObjectHub to work out how the original Query service design works 
now it has been split off from the core objecthub.

--
Steve Alexander