[Zope-dev] more on stacked component registries

[Philipp von Weitershausen]

On 5 Feb 2008, at 19:23 , Chris Withers wrote:
> Stephan Richter wrote:
>> On Tuesday 15 January 2008, Chris Withers wrote:
>>> For what I'm after, I need to have a more dynamic buildup of
>>> registrations based on which objects have been traversed through.
>> Right. I think the component architecture is not really made for  
>> this.
>
> Sure it is, I'm talking about what basically happens with nested  
> site managers. The problem is that the current nesting  
> implementation seems predicated on zodb-like persistence. I'm  
> looking at storing all "data", including site managers, in a  
> relational database. The actual folder structure should remain as  
> static as it does with zodb...

Well, each place in the ZODB will still know that it is a site, i.e.  
that it has a site manager associated, right? Because then you can  
easily track down the same registry over and over again. You could  
probably even register them as global utilities for easy access (like  
it's done with other registries, e.g. the ones from z3c.baseregistry).

>> I think it would be easier to turn on/off registrations by using  
>> dynamically directly provided interfaces (via a proxy) or use  
>> security.
>
> Not sure what you mean by either of these...

You can change which adapters are found for a particular object by  
applying marker interfaces.

>>> - stack the registries up during travesal in some way. I guess this
>>>   would be a variant of what's done now with current nested  
>>> registries.
>>>   Is this feasible? Will there be performance problems?
>> I think the performance would decrease, because caches cannot be  
>> built up. Also, you then must be able to access this custom  
>> registry. Remember, this must be all in memory, because of thread- 
>> safety!
>
> Yeah, but this is what happens more static-ly with the existing site  
> managers, right?

I'm not sure how the ZODB-based registries do caching. I strongly  
suspect that their caches may be garbage-collected at any time after  
the request is over. Also, let's not worry about premature  
optimizations right now...

>>> - use one global registry and add/remove registrations during  
>>> traversal
>>> as necessary. How fast is registration/unregistration of adapters  
>>> and
>>> the like? How many adapter adds/removes at a traversal node would it
>>> take to really slow things down?
>> You cannot do this; it is not thread-safe.
>
> Well okay, one registry per thread... would that work?

So you would basically copy the whole global registry to a thread- 
local variable at the beginning of the request, then modify it and  
then throw it away afterwards? Doesn't sound very clever to me...