Re: IMPORTANT xAP Basic Status and Control

[Stuart Booth]

Kevin,

Part-way through reading this document. Interesting reading. I showed
it at work at lunch today. The other guys thought I must be mad
reading specs like this in my lunch hour :-)

Anyway, whilst I'm waiting on various aspects of my Server reinstall
here (zero xAP progress until I get source control back online again,
basically) I'm reading parts of your document. I'll post separate
messages.

1. I like all the message body formatting options!

Because of the pair name becoming a critical data value
(Lounge.TableLamp=ON), this means that you only have one shot at the
data. You can't pass 2 bits of information.

But since this is a minimum level system I can't think of any cases
where this would be needed. They probably exist though.

Presumable this situation could be solved with additional sub-address
components.

2. I appreciate the problem of decorative name to sub-address ID
matching. Using the sub-address IDs seems a very efficient solution,
but its very compactness and in-built efficiency makes the messages
unreadable to the eye.

Perhaps an additional information block would be helpful for debugging
that includes the linkage between the IDs used in the message and
their full decorative name, where the info block is optional?

Class=xAPcmd.state
output.state
{
01=ON
02=OFF
}
output.devices
{
01=Lounge.TableLamp
02=Lounge.CentreLight
}

3. xAPcmd or xAP-cmd?

I've separated xAP and <type> with a dash in all my uses of it. A
minor, minor thing, but this matters right now as it'll be definitive
from now on I feel.

It's an extra wasted character, so drop it from all schemas?

4. Level. How about a 'balance' type device whose values range from
-100 ... 0 ... +100? I suppose that is covered sort of in 0-100% with
a mid-point at 50%.

5. Discussion point on compound and single responses. You might have
the situation where a 'compound' response only includes the one
response anyway, thus making it a single response. I don't think
there's a need for different class names in this at all.

6. Compound status example request. You use:

{
}

So no body content is included. Seems wasteful to force a dummy
section name in this case. This is the sort of thing I'd just notice
was missing and be happy about, although I'm not sure if my framework
demands a minimum of at least one block in the body of the message, or
if the xAP spec demands this also.

If a block is required I'd go with using the same section name on the
block and just have it empty. Then again, this suggests NO devices are
to be queried rather than all.

All for now,

S
--
Stuart Booth <<a
href="/group/xAP_developer/post?postID=J0bWGriT0duPBg1m_1-7O4QV-zW8C46xQ5v8OWsA1zfVlrZOkeTeUCdWVcXuJz70DXj4bl1loTuAEekJhKpzudSi">stuart@x...</a>>
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>