On Thursday 07 June 2001 21:28, Phillip J. Eby wrote:
> Yep. One of the last two times I spoke with Jim in person (either
> the January DC visit or IPC 8, I forget which), he said something
> about it maybe being a good idea to have some kind of priority system
> like that. I'd love to see something like it exist, if it would make
> some of ZPatterns' hackery unnecessary.
Yes, I would too. I'm happy to see we're in complete agreement.
> The implementation could consist of two subscription queues:
> ruleAgents and indexingAgents. ZCatalog would register in
> indexingAgents, and ZPatterns objects would register in one or the
> other, usually ruleAgents. (I can think of some circumstances where
> it would be nice to use the indexingAgents queue, but right now
> ZPatterns apps have to work around this by defining their rules in
> execution priority order.)
Ah-ha, this is sounding familiar. You talked about rule agents and
indexing agents in the ZPatterns wiki.
> Upon being told to perform a transaction or subtransaction commit,
> the transaction would notify all the ruleAgents, and then all the
> indexingAgents. Objects could still subscribe to either queue while
> this notifying is taking place. (So that triggered actions could
> cause indexish objects to register as indexingAgents, not to mention
> causing updated objects to fire additional triggers.)
> Once all agents in a queue are notified, that queue should be cleared
> so that notifications are on a per-subtransaction basis. Once both
> queues are cleared, normal transaction behavior goes forward.
Would you say this would occur before tpc_begin() messages or just
> Hm. That's simpler than I thought it was going to be. Shoot, I can
> even see how to implement it as a runtime patch, that would've been
> simpler than all the shenanigans ZPatterns goes through to fake out
> the transaction machinery... and it's a better
> implementation. Ah well. At the time I wanted to avoid trying to
> convince Jim to add machinery to transactions "just" for ZPatterns,
> given that ZPatterns wasn't a particularly established product at the
> Let me know if you guys put something like this in, though, and I'll
> definitely look at reworking ZPatterns to use the mechanism. It
> could potentially cut a lot of code out and improve the robustness at
> the same time.
I don't foresee us adding this capability right away since we need to
understand it better and it only applies to one working product and a
hypothetical product. I'd suggest you go ahead with the runtime patch.
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -