Forum OpenACS Development: Re: imap4 for ACS Mail Lite incoming email

Posted by Antonio Pisano on
Hoping to clarify about callbacks, even if in a very non-scientific way: one defines contracts for functions in package A, then packages B, C, D... can all define implementations of such contracts that will all fire in theoretically unspecified order (but alphabetical in practice) whenever one calls:

callback the::contract::name -args $args

Basically the system will loop through every registered implementation and fire it one at a time, lappending each result to the final return value of the callback call.

This I guess you have seen already, but for reference:

Posted by Benjamin Brink on
Hi Antonio,

Thank you for the explanation. Indeed. The main point of confusion for me has been the concept that a callback collects outputs of contracts instead of each contract terminating as a separate thread.

I was expecting a callback to execute contracts independently via new threads.

Fully sequential execution within the same thread seems prone to having a contract adversely affect execution of contracts that follow (in same thread), since contracts are made and operate outside of the callback environment.

This arrangement has a variety of implications. Consequences include a contract possibly affecting input parameters or having a procedure susceptible to timeout conditions that delay processing of some contracts beyond a scheduled callback's expected execution time --when the callback is triggered as part of a scheduled proc.

Designing callbacks (and contracts) that work within this environment is critical for a centralized service, such as ACS Mail Lite.

Questions need answered in the design of a callback: Should a callback 'learn' to ignore a contract with a history of taking 'too long' to process or when a contract errors a certain number of times?

Now that the confusion is cleared, I'm set to resolving the challenges.