[Message Prev][Message
Next][Thread Prev][Thread Next][Message
Index][Thread Index]
Re: Re: Proposals for xAP TSC
--------------020301000307050503040607
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Hi Daniel,
I must have missed the original post. I'm busy over this weekend but
I'll read and respond on Monday.
Regards,
Lehane
Daniel Berenguer wrote:
>
>
> No comments? Come on guys! ;-)
>
> --- In xAP_developer@xxxxxxx
> <mailto:xAP_developer%40yahoogroups.com>,
Daniel Berenguer
> <dberenguer@...> wrote:
> >
> > I'm just starting to code the TSC extension for the opnode libxap
> > library and have some remarks regarding the current TSC specs:
> >
> > Question DB1: (DB is me :-))
> > Setpoints will force us to manage at least two values per
endpoint (a
> > temperature value and a setpoint) and an additional keyword
> > ("setpoint") in the section title. Generic IO devices
will have to
> > provide a way to associate an optional setpoint to any generic
analog
> > input, not very straightforward.
> >
> > Proposal DB2:
> > I suggest to remove the setpoint feature and take any real
setpoint as
> > a new endpoint. IMO, the "one value per endpoint"
paradigm is much
> > easier to implement in embedded devices, against the
"multiple values
> > per endpoint". When I say "value" I really mean
"variable value". xAP
> > BSC brought this problem too, where a single endpoint could have
a
> > value (text or level) and a binary state. We could then simplify
> > things for TSC. Doing this, we'll be able to compact endpoint
tables
> > in memory and simplify message parsing.
> >
> > Question DB2:
> > I was expecting to deal with TSC.capability as an optional class,
not
> > supported in the first versions. TSC.info is IMO a simpler way to
> > discover devices because it's sent periodically whilst
TSC.capability
> > is sent only as a response to a TSC.query with request.capability
> > body. Am I right? I know that TSC.capability will provide more
> > detailed results than TSC.info but for most applications I think
that
> > infos will be more than enough. I just try to start things in a
simple
> > manner.
> >
> > Proposal DB2:
> > OK, assuming that we're allowed to not to support TSC.capability,
> > could we maybe move the type=input/output information to the
TSC.info
> > body? Master applications like opn-max need to know whether
endpoints
> > are controllable (outputs) or not (inputs). BSC contained this
> > information in the section ttile. E.g: output.state.1,
input.state.1.
> > I'd suggest to follow the BSC way regarding this too. As result,
we'd
> > have section titles like the following ones, at least for TSC
cmd's,
> > events, infos and queries:
> >
> > input.humidity
> > output.temperature (an example of setpoint, see Question DB2)
> > output.level
> >
> > instead of:
> > event.humidity
> > cmd.temperature
> > info.level
> >
> > In fact, "event", "cmd", "info" and
"query" are already contained in
> > the xAP class field.
> >
> > Question DB3:
> > "unit" field is supposed to be mandatory in TSC
commands, events and
> > infos. I can agree in that events and infos must contain the unit
> > information but, why commands? I'm thinking in master controllers
like
> > opn-max: A very lightweight implementation of TSC would force the
> > controller to maintain the unit information in the table of
endpoints
> > too.
> >
> > Proposal DB3:
> > Remove "uni"t from the TSC.cmd body. In fact, TSC.cmd's
could
> > transport only the relevant information to be changed in the
target
> > device, something like xAP BSC
> > This has a minor importance but I'd also make unit optional when
no
> > unit is specified (no unit field instead of unit=arb).
> > This proposal would abstract the source device from the type of
data
> > to be controlled in the target device. This would reduce the size
of
> > TSC commands too.
> >
> > Question DB4:
> > Why ID=* is not accepted? How can we control multiple endpoints
in a
> > single TSC.cmd body?
> >
> > Proposal DB4:
> > Allow ID=*. This can be useful to reset outputs for example.
> >
> > Question DB5:
> > According to the TSC draft, counters are a special case where
inbound
> > commands produce outbound infos. This will force us to treat
counters
> > apart, not as any other endpoint.
> >
> > Proposal DB5:
> > We should keep here the command->event / query->info
mechanism too,
> > similar to xAP BSC. Thus, reseting a counter will proce a TSC
event,
> > not an info.
> >
> > Question DB6:
> > For real alarms, is the alarm body mandatory?
> > Is the capability class mandatory?
> >
> > Proposal DB6:
> > Make any body other than cmd, event and info optional. This will
allow
> > lightweight implementations of TSC (very important for the first
> > adoption stages). Again, this will compact messages in simple
> > implementations (embedded controllers).
> >
> > As you see, most of my questions/proposals are aimed to make xAP
TSC
> > more compact, simpler to implement and more similar to BSC. This
will
> > definitely simplify its adoption, at least in embedded devices,
and
> > will make TSC and BSC more cohabitable.
> >
> > Thanks for your time,
> >
> > --
> > Daniel Berenguer
> > http://www.usapiens.com <http://www.usapiens.com>
> > http://www.opnode.org <http://www.opnode.org>
> >
>
>
--------------020301000307050503040607
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<head>
<style type="text/css">
<!--
/* start of attachment style */
.ygrp-photo-title{
clear: both;
font-size: smaller;
height: 15px;
overflow: hidden;
text-align: center;
width: 75px;
}
div.ygrp-photo{
background-position: center;
background-repeat: no-repeat;
background-color: white;
border: 1px solid black;
height: 62px;
width: 62px;
}
div.photo-title
a,
div.photo-title a:active,
div.photo-title a:hover,
div.photo-title a:visited {
text-decoration: none;
}
div.attach-table div.attach-row {
clear: both;
}
div.attach-table div.attach-row div {
float: left;
/* margin: 2px;*/
}
p {
clear: both;
padding: 15px 0 3px 0;
overflow: hidden;
}
div.ygrp-file {
width: 30px;
valign: middle;
}
div.attach-table div.attach-row div div a {
text-decoration: none;
}
div.attach-table div.attach-row div div span {
font-weight: normal;
}
div.ygrp-file-title {
font-weight: bold;
}
/* end of attachment style */
-->
</style>
</head>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01
Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<!-- **begin egp html banner** -->
<br><br>
<!-- **end egp html banner** -->
Hi Daniel,<br>
I must have missed the original post. I'm busy over this weekend but
I'll read and respond on Monday.<br>
<br>
Regards,<br>
Lehane<br>
<br>
<br>
Daniel Berenguer wrote:
<blockquote cite="mid:hqcpti+9qvm@xxxxxxx"
type="cite"><span
style="display: none;"> </span>
<div id="ygrp-text">
<p>No comments? Come on guys! ;-)<br>
<br>
--- In <a moz-do-not-send="true"
href="mailto:xAP_developer%40yahoogroups.com";>xAP_developer@<wbr>yahoogroups.<wbr>com</a>,
Daniel Berenguer <dberenguer@<wbr>...> wrote:<br>
><br>
> I'm just starting to code the TSC extension for the opnode
libxap<br>
> library and have some remarks regarding the current TSC
specs:<br>
> <br>
> Question DB1: (DB is me :-))<br>
> Setpoints will force us to manage at least two values per endpoint
(a<br>
> temperature value and a setpoint) and an additional
keyword<br>
> ("setpoint") in the section title. Generic IO devices
will have to<br>
> provide a way to associate an optional setpoint to any generic
analog<br>
> input, not very straightforward.<br>
> <br>
> Proposal DB2:<br>
> I suggest to remove the setpoint feature and take any real
setpoint as<br>
> a new endpoint. IMO, the "one value per endpoint"
paradigm is much<br>
> easier to implement in embedded devices, against the
"multiple
values<br>
> per endpoint". When I say "value" I really mean
"variable value".
xAP<br>
> BSC brought this problem too, where a single endpoint could have
a<br>
> value (text or level) and a binary state. We could then
simplify<br>
> things for TSC. Doing this, we'll be able to compact endpoint
tables<br>
> in memory and simplify message parsing.<br>
> <br>
> Question DB2:<br>
> I was expecting to deal with TSC.capability as an optional class,
not<br>
> supported in the first versions. TSC.info is IMO a simpler way
to<br>
> discover devices because it's sent periodically whilst
TSC.capability<br>
> is sent only as a response to a TSC.query with
request.capability<br>
> body. Am I right? I know that TSC.capability will provide
more<br>
> detailed results than TSC.info but for most applications I think
that<br>
> infos will be more than enough. I just try to start things in a
simple<br>
> manner.<br>
> <br>
> Proposal DB2:<br>
> OK, assuming that we're allowed to not to support
TSC.capability,<br>
> could we maybe move the type=input/output information to the
TSC.info<br>
> body? Master applications like opn-max need to know whether
endpoints<br>
> are controllable (outputs) or not (inputs). BSC contained
this<br>
> information in the section ttile. E.g: output.state.<wbr>1,
input.state.<wbr>1.<br>
> I'd suggest to follow the BSC way regarding this too. As result,
we'd<br>
> have section titles like the following ones, at least for TSC
cmd's,<br>
> events, infos and queries:<br>
> <br>
> input.humidity<br>
> output.temperature (an example of setpoint, see Question
DB2)<br>
> output.level<br>
> <br>
> instead of:<br>
> event.humidity<br>
> cmd.temperature<br>
> info.level<br>
> <br>
> In fact, "event", "cmd", "info" and
"query" are already contained
in<br>
> the xAP class field.<br>
> <br>
> Question DB3:<br>
> "unit" field is supposed to be mandatory in TSC
commands, events
and<br>
> infos. I can agree in that events and infos must contain the
unit<br>
> information but, why commands? I'm thinking in master controllers
like<br>
> opn-max: A very lightweight implementation of TSC would force
the<br>
> controller to maintain the unit information in the table of
endpoints<br>
> too.<br>
> <br>
> Proposal DB3:<br>
> Remove "uni"t from the TSC.cmd body. In fact, TSC.cmd's
could<br>
> transport only the relevant information to be changed in the
target<br>
> device, something like xAP BSC<br>
> This has a minor importance but I'd also make unit optional when
no<br>
> unit is specified (no unit field instead of unit=arb).<br>
> This proposal would abstract the source device from the type of
data<br>
> to be controlled in the target device. This would reduce the size
of<br>
> TSC commands too.<br>
> <br>
> Question DB4:<br>
> Why ID=* is not accepted? How can we control multiple endpoints in
a<br>
> single TSC.cmd body?<br>
> <br>
> Proposal DB4:<br>
> Allow ID=*. This can be useful to reset outputs for
example.<br>
> <br>
> Question DB5:<br>
> According to the TSC draft, counters are a special case where
inbound<br>
> commands produce outbound infos. This will force us to treat
counters<br>
> apart, not as any other endpoint.<br>
> <br>
> Proposal DB5:<br>
> We should keep here the command->event / query->info
mechanism too,<br>
> similar to xAP BSC. Thus, reseting a counter will proce a TSC
event,<br>
> not an info.<br>
> <br>
> Question DB6:<br>
> For real alarms, is the alarm body mandatory?<br>
> Is the capability class mandatory?<br>
> <br>
> Proposal DB6:<br>
> Make any body other than cmd, event and info optional. This will
allow<br>
> lightweight implementations of TSC (very important for the
first<br>
> adoption stages). Again, this will compact messages in
simple<br>
> implementations (embedded controllers)<wbr>.<br>
> <br>
> As you see, most of my questions/proposals are aimed to make xAP
TSC<br>
> more compact, simpler to implement and more similar to BSC. This
will<br>
> definitely simplify its adoption, at least in embedded devices,
and<br>
> will make TSC and BSC more cohabitable.<br>
> <br>
> Thanks for your time,<br>
> <br>
> -- <br>
> Daniel Berenguer<br>
> <a moz-do-not-send="true" href="http://www.usapiens.com";>http://www.usapiens<wbr>.com</a><br>
> <a moz-do-not-send="true" href="http://www.opnode.org";>http://www.opnode.<wbr>org</a><br>
><br>
<br>
</p>
</div>
<!-- end group email --></blockquote>
<br>
<!-- **begin egp html banner** -->
<br>
<br>
<!-- **end egp html banner** -->
<div width="1" style="color: white; clear:
both;"/>__._,_.___</div>
<!-- Start Recommendations -->
<!-- End Recommendations -->
<!-- **begin egp html banner** -->
<img src="http://geo.yahoo.com/serv?s=97476590/grpId=9629476/grpspId=1705007709/msgId=2122/stime=1271525666";
width="1" height="1"> <br>
<!-- **end egp html banner** -->
<!-- **begin egp html banner** -->
<br>
<div style="font-family: verdana; font-size: 77%; border-top: 1px
solid #666; padding: 5px 0;" >
Your email settings: Individual EmailTraditional <br>
<a href="http://groups.yahoo.com/group/xAP_developer/join;_ylc=X3oDMTJmaDlqZjFuBF9TAzk3NDc2NTkwBGdycElkAzk2Mjk0NzYEZ3Jwc3BJZAMxNzA1MDA3NzA5BHNlYwNmdHIEc2xrA3N0bmdzBHN0aW1lAzEyNzE1MjU2NjY-";>Change
settings via the Web</a> (Yahoo! ID required) <br>
Change settings via email: <a href="mailto:xAP_developer-digest@xxxxxxx?subject=Email
Delivery: Digest">Switch delivery to Daily Digest</a> <a
href = "mailto:xAP_developer-fullfeatured@xxxxxxx?subject=Change
Delivery Format: Fully Featured">Switch to Fully Featured</a>
<br>
<a href="http://groups.yahoo.com/group/xAP_developer;_ylc=X3oDMTJkN2NndW50BF9TAzk3NDc2NTkwBGdycElkAzk2Mjk0NzYEZ3Jwc3BJZAMxNzA1MDA3NzA5BHNlYwNmdHIEc2xrA2hwZgRzdGltZQMxMjcxNTI1NjY2";>
Visit Your Group
</a>
<a href="http://docs.yahoo.com/info/terms/";>
Yahoo! Groups Terms of Use
</a>
<a href="mailto:xAP_developer-unsubscribe@xxxxxxx?subject=Unsubscribe";>
Unsubscribe
</a>
<br>
</div>
<br>
<!-- **end egp html banner** -->
<div style="color: white; clear:
both;"/>__,_._,___</div>
</body>
</html>
--------------020301000307050503040607--
xAP_Development Main Index |
xAP_Development Thread Index |
xAP_Development Home |
Archives Home
|