Chris Withers wrote:
But what about, for example, databases which don't have an efficient way to do callbacks to external applications? You may have to do a "SELECT id FROM tblObjects WHERE timestamp > some_time" or a similar kludge from a polling server. You may want this server to reside at the same location as the RDBMS, rather than as a thread in Zope.seb bacon wrote:Since every storage will have its own unique notification scheme, which may be more or less inefficient (worst case scenario, periodic polling of entire storage for recently modified items), it might make sense to have a "notification server." It would make it simpler for users to create custom storage transaction alert handlers.
For different cache invalidation scenarios, Zope could poll the server as well as get poked.
I'd prefer just to have a method somewhere that, as Shane suggested, could be hit by URL, etc.
A whole seperate server seems like overkill...
I'm worrying that if we are not to be restricted to Oracle or bleeding edge kernels, the notification part of the cache invalidation scheme may be (a) kludgy, (b) inefficient, and (c) utterly different in design between different storages. A server could offer a layer of indirection which could provide a single API for Zope to see, an opportunity to take the process load somewhere else, and a pluggable interface for writers of storages.
On the other hand, I don't know much about RDBMS callbacks or filesystem accounting, so I could be inventing a problem to solve :-)
seb
_______________________________________________
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists - http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
