Tres Seaver wrote:
>> The reason being that, for a long time, I've wanted to see a persistent
>> registry that stored in a rdb rather than zodb.
> I don't know what that would look like.
I have ideas about what I'd like it to look like from a user's
perspective, but sadly not much in the way of code, rdb schema, etc...
>> However, I'm a bit stumped at how to implement this and certainly having
>> the zodb-based registry mixed in with the zope.component code confused
>> the hell out of me when I last looked. The one that particularly got me
>> was how, in a multi-process/multi-thread setup such as a wsgi app, you
>> would get other threads'/processes' registries to update themselves when
>> a registry in one thread/process was changed. Any ideas how to do this?
> Nope. I've never given it any thought.
I have, and as a result I'd happilly *pay* someone else to develop a
decent solution ;-)
>> We do actually have this problem with the text-file based registry, it's
>> just that we accept a restart of the server is needed when that text
>> file changes. A "nice to have" would be an equivalent of apache's reload
> I don't actually understand the usecase: changing configure.zcml is a
> development activity, not a sysadmin one.
Yeah yeah, whatever ;-)
I'm a developer, and I edit httpd.conf plenty, I think this distinction
is pretty meaningless...
>> Is anyone else interested in this kind of stuff?
> Theoretically, yes. Practically, no: I'd rather keep my startup times
> under a second. ;)
Well, what I really care about doesn't actually have to do with startup
times. I'd like sub-second startup times too, but I'd also like to have
an ISite (what a horrible, wrong name :-S) implementation that worked in
a multi-threaded and/or multi-process environment and didn't store its
data in ZODB.
I'd *also* like:
>>> a = root.siteA.objecta
>>> b = root.siteB.objectb
>>> a.__class__ is b.__class__
>>> adapter1 = getAdapter(a,ISomething,context=a)
>>> adapter2 = getAdapter(b,ISomething,context=b)
>>> adapter1.__class__ == adapter2.__class__
...if you see what I mean? (ie: adapter lookup based on object traversal
path rather than some notion of "current overall request traversal
path", which doesn't make sense if siteA and siteB register different
ISomething adapters for a.__class__.
Of course, having ISomething(a) and ISomething(b) do this would be super
super cool ;-)
As I said, I'm prepared to pay for anyone who can make this happen :-)
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -