[Zope3-dev] ObjectHub: Kill the plugins!

[Gary Poster]

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).  

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.

In a similar vein, we would have, 

 * a RelationshipService (client of the object hub; clients would
usually use it with the MetadataService; it might be nice to have this
understand the TBD query objects as well; contains addable relationship
types)

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.

Gary



On Fri, 2002-10-18 at 06:56, Steve Alexander wrote:
> 
> > PROPOSAL: Eliminate the concept of ObjectHub plugins.  The ObjectHub has
> > a simple contract: keep track of integer-to-path mapping, act as a
> > transparent event channel, and generate hub events for its subscribers. 
> > That's it.  Any clients doing other tasks live elsewhere, using the
> > ComponentArchitecture infrastructure, and have their own interfaces.
> 
> So, is another way of thinking about this to still have what were 
> formerly known as "PlugIns", but to have them in a different place, or 
> in different places?
> 
> I like the idea of keeping the ObjectHub very simple, and I believe we 
> discussed this before, with many points in its favour.
> 
> If we agree that this is the way forward, then I think we need to design 
> a service for the other role of the obejecthub+pluigins: answering Queries.
> 
> So, the default Query service would consist of a container for Plugins, 
> many of which are subscribed to the ObjectHub.
> 
> As components outside of the ObjectHub were always allowed to subscribe 
> to ObjectHubEvents, in the new scheme of things, we have just split the 
> original ObjectHub into two parts: focused objecthub, and query service.
> 
> --
> Steve Alexander
> 
> 
>