Apps Messaging - Semantics of a Message
John Taylor
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
> interface.
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.
One
> 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-)
>
> Cheers,
> -Mike
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/apps/attachments/20070407/cdf61846/attachment.html>
More information about the apps
mailing list