Re: Query / Response type messages

[Edward Pearson]

Well, I didn't start out with particularly strong views on the
targetted response to status request; just seemed sensible for some
reason. Now having read the thread below I think:

1) My original intention was to make it easier for the requestor to
identify the response to their request. And putting their source in
the reply body would be fine for that - maybe that should be done in
addition. It's just that it feels like a private conversation is
going on: you ask a question, I tell you the answer. Others can
listen in if they've taken the decision to listen to all
conversations. Otherwise they should listen just for untargetted
status.event and status.info messages that I send; those should keep
them well informed.

Maybe you're thinking that I'm suggesting something where all status
messages are targetted - not at all; purely the responses to
specific requests. Devices should report status change 'events' and
periodic 'info' messages as broadcast as per your original
suggestion. I'm just adding a little extra on top of that. Like
Stuart says; different levels.

2) Don't follow the 'increase loading on limited capability devices'
line. Having very specific responses targetted keeps irelevant stuff
away from nodes that aren't interested.

3) Oh, what's the "ACK / sequencing suggestions" stuff? - I may
have
missed something here. Where's it documented (or should I just
search the archive for ACK?)

Comiserations on the hard drives.

Always a fan of the gross mis-quote... To loose one hard drive is
bad luck; but to loose two seems careless :->

Lastly, is there any better way of positing to the group without
using this 'pigging' web form?

Happy New Year!

Edward

--- In <a
href="/group/xAP_developer/post?postID=a9J1A32OKu50u4ZSaBddiurOTpenW9kDyopPE3i1qDHtL4jXnwLV0ECMz8QKdvrEt9jwz2am_vDA63EbCcfBA7JkSQ">xAP_developer@xxxxxxx</a>,
Stuart Booth <lists@x> wrote:
> On Thu, 1 Jan 2004 18:15:13 -0000, "Kevin Hawkins"
> <lists@u...> wrote:
>
> > > On Thu, 01 Jan 2004 16:46:40 -0000, "Edward
Pearson"
> > > <edward.mailgroup@b...> wrote:
> > >
> > > >I think the xAPstatus.response should be targetted at
the
> > > sender of the
> > > >xAPstatus.request.
> > >
> > > Now there's an interesting idea I hadn't thought of
> > > before. I think I shall update my various applications to
> > > do that as I like that.
>
> >I am interested in what you feel the benefit is here - except
obviously the
> >originator knows that the device responded directly to this
request.
>
> That's what appeals to me. Somebody has requested some information.
> Untargetted responses are vague. If there were 2 slightly different
> information requests sent at roughly the same time, which is the
> response that I want? I have to inspect the query, hopefully
embedded
> within the response block and compare it to what I had asked,
which I
> now have to keep around.
>
> >There was some thought went into this original non targeted
response when I
> >suggested it. Given that the device is reporting current status
then all
> >devices are interested in this info, not just the one that
originated the
> >request.
>
> That information is still available to anybody else, and with the
> addition of the original query within the reply block anybody else
has
> all the information they want.
>
> > Some devices may filter incoming packets based on 'target' and
> >could therefore drop the response.
>
> Filtering out targetted messages, and listening only to general
> untargated broadcasts, or those targetted at them?
>
> > If targeting was used then listeners
> >interested in status would have to receive and parse ALL xAP
messages (even
> >ones not targeted at themselves) to inspect the schema before
knowing
> >whether it was a status message.
>
> This seems like a good argument for placing the response messages
in a
> different schema as it allows a device to filter out messages at
the
> header level.
>
> Seems to be pro's and con's for each, like Edward says, "I think
the
> best combines features from each."
>
> > This could significantly increase loading
> >on limited capability devices. Therefore I felt it was wrong and
all status
> >information should be sent untargeted.
>
> There's differing levels of status information here I feel.
>
> One is the status information and events generated by the device
e.g.
> Now.Playing when the track changes, and the informational "This
is
> where I'm at right now".
>
> Then there are the directly addressed responses requesting
particular
> information.
>
> The former would be untargetted, the latter to be targetted at the
> inquisitor.
>
> S
> --
> Stuart Booth <stuart@x...>
> xAPFramework.net - a xAP software development framework for .net
>
> <a href="http://www.xapautomation.org/";>http://www.xapautomation.org/</a>
<a href="http://www.xapframework.net/";>http://www.xapframework.net/</a>