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

Collapse
5: Re: imap4 for ACS Mail Lite incoming email (response to 4)
Posted by Benjamin Brink on 07/11/17 03:03 AM
Hi Malte,

Thank you for offering the code example. Examples are handy.

At this point, my obstacle is in understanding how OpenACS callbacks work.

I understand the theory. Callbacks register events. And contracts are triggered by events. And I'm familiar with even driven programming. And yet, in my own typical way, I'm unable to yet make sense of how it's implemented in OpenACS. I'm relying heavily on existing callback cases in OpenACS, and document you wrote for Incoming email https://openacs.org/xowiki/incoming_email to help sort it out. Thank you for that documentation.

cheers,
Ben

Collapse
7: Re: imap4 for ACS Mail Lite incoming email (response to 5)
Posted by Antonio Pisano on 07/11/17 03:44 PM
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:
https://openacs.org/api-doc/proc-view?proc=callback&source_p=1

Collapse
8: Re: imap4 for ACS Mail Lite incoming email (response to 7)
Posted by Benjamin Brink on 07/11/17 07:31 PM
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.

cheers,
Ben