Subject: RE: [XCON] Call for Consensus and Discussion: Data Model

From: "Oscar Novo (JO/LMF)" <[email-masked]>
Date: Fri, 2 Dec 2005 12:46:54 +0100

Hi Henning,

I don´t understand why you say the asynchronous query mechanism is harder to program than the synchronous one. Could you please tell me in what things one alternative is more difficult to program than the other?

Oscar

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: 2. joulukuuta 2005 6:11
To: Oscar Novo (JO/LMF)
Cc: [email-masked]; Even, Roni; XCON-IETF
Subject: Re: [XCON] Call for Consensus and Discussion: Data Model

 From a practical perspective, you can indeed get a SUBSCRIBE to tickle a NOTIFY with the current state, but that seems far harder to program than a synchronous "query" mechanism. Thus, while this does duplicate mechanisms in a strict sense, the purpose and application is sufficiently different that this seems less harmful than the alternative.

I would also argue that trying to develop an XCON-specific publish/subscribe/notify mechanism seems of dubious utility unless existing mechanisms are clearly incapable of handling the chore. One of the nicer aspects of re-using the event mechanism is that a lot of the tools, such as the privacy rules, can probably be drafted into service fairly easily. That way, we don't have to develop new XML to restrict who can get notified of conference events.

_______________________________________________
XCON mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/xcon

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 02 Dec 2005 22:20:42 -0500

Oscar Novo (JO/LMF) wrote:
> Hi Henning,
> 
> I don´t understand why you say the asynchronous query mechanism is
> harder to program than the synchronous one. Could you please tell me
> in what things one alternative is more difficult to program than the
> other?

Let me try to be more precise. A simple retrieval is programmed 
something like (writing PHP-style)

$var = query("http://example.com/whatever")

or some similar construct (e.g., a SOAP library call), probably wrapped 
in a 'catch' of some sort to deal with exceptional conditions such as a 
timeout or network failure.

For an asynchronous event mechanism, you'd have to do something like

- issue the SUBSCRIBE request and deal with any errors; probably block 
the thread if the value of the conference state is needed for further 
computation

- set up a call-back function that is invoked by the NOTIFY showing up 
at some unspecified time in the future; associate the NOTIFY with the 
pending request, as it may arrive on a completely different TCP or UDP 
socket than the SUBSCRIBE

- set up a timer so that the program doesn't freeze if the NOTIFY 
doesn't show up after some reasonable amount of time; handle the time-out

- unblock the thread in the call-back function and pass the results back 
through some kind of shared thread variables

This can all be done, but a simple request for a value becomes a fairly 
substantial effort. Unfortunately, most languages seem to be ill-suited 
for event-based programming.

Henning