seb bacon wrote:
Well, if by server you could mean "script that gets run by cron every 1 minute and hits a URL in Zope if something has changed", then I might be in agreement ;-)I'd prefer just to have a method somewhere that, as Shane suggested, could be hit by URL, etc.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.
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.I think this is as "such is life" problem. Provided AdaptableStorage provides some way (exposed url?) for an external process to say that things have changed, I think that's the best form of flexibility we can provide.
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists - http://lists.zope.org/mailman/listinfo/zope-announce