Apps Messaging - Semantics of a Message
jontayler at gmail.com
Sat Apr 7 07:06:27 PDT 2007
On 4/7/07, Mike Fitzpatrick <mjfitzpatrick at gmail.com> wrote:
> Hi John,
> In the python case you mention there is nothing that prevents an
> interface from being developed that works synchronously for that
This is true, you can always write a module that will do all this for you
and hide it away, but we'd have to provide one for every environment where
it might be needed.
> What I want to avoid is writing synch behavior into the
> spec and running into the problem of blocked processes where
> we have an app that crashes or just runs for a long time.
I want to make it clear that I'm not suggesting a synch interface instead -
I agree that an asynch interface is essential. I'm just arguing in favour
of developer choice and simplicity. If a developer chooses to use the synch
interface he should only end up blocking in his own application...the hub
shouldn't reject other messages in the meantime.
> thing I haven't discussed is a 'timeout' or 'time-to-live' property
> of messages. For the moment we're considering interactive
> response times, however an analysis app, or one that spends
> time downloading data from the network might not reply for
> several minutes or more. Asynch behavior allows us to work
> around that and handle a response much later in time, we could
> also specify the idea of 'alarms' that let us punt if no response
> is received after a fixed time.
> Of course, there are those amongst us who would claim that we
> should build a VOevent handler into the system to deal with this 8-)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the apps