[Message Prev][Message
Next][Thread Prev][Thread Next][Message
Index][Thread Index]
Re: Re: Proposal / RFC: Change xAP wire format
--------------040806040001060100010602
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
I guess there are a number of issues to address, JSON adoption being
perhaps one of them as part of a package to next gen xAP.
As with all things technology based, things progress. If you were
starting with the proposal of an HA protocol/message structure today
then something that could be parsed automagically, in pretty much any
development environment, would be high on the list of desirables. So I
guess the question is whether xAP should evolve to xAPJ or something
completely new?
Secondly, if you were working on the assumption of TCP based networking
(and it must be that 99.999% of working implementations are..), would
you use the UDP broadcast mechanism as-is, without some form of assured
delivery? Whilst rare, UDP packet loss, can cause significant issues
when xAP is being used for heating control, lighting,
sprinklers/irrigation, etc., where there is M2M interaction. Wireless
only exacerbates this. So at some level, I feel, this needs addressing
as part of a next generation xAP.
BSC, hmm. Absolutely one of the greatest strengths, as Kevin says, and
also the Achilles heel in that shoehorning everything into the schema
has broken it and reduced the introduction and adoption of more relevant
ones. In next gen xAP I think this has to be addressed by being more
prescriptive(in many areas) and by a fast track mechanism for the
ratification of new schemas and ideas.
Which of course comes down to how should any evolution be managed? Who
should manage this? Should there be a committee? An RFC like process?
Should non-standard implementations be 'jumped on', to maximise long
term interoperability? Is there any appetite for this amongst the
developer community?
Lehane
On 08/07/2011 11:39, Kevin Hawkins wrote:
>
> I'm fairly enthused with using JSON too, I've been using it a little
in
> xAP Flash and now in the iViewer xAP implementation. It would seem a
> good fit for xAP.
>
> However I feel there are many other aspects of moving xAP forward that
> we need to address, mostly time and commitment related in order to get
> resources and visibility out there. I am not sure we have that
> capability at the moment.
>
> There are certainly aspects of BSC that we could improve, a classic
> example is how to represent negative values e.g. temperature for
> example. I have posted quite a bit both on and off list with people
> about this, including Daniel, about what we might do here. There are a
> few unofficial BSC enhancements that are in fairly widespread use
> (choice devices and level offsets for example) but no official BSC2.
> TSC I feel is not ready yet for adoption and I know of no TSC aware
> applications.
>
> BSC is the most widely adopted schema in the xAP world today and is as
> near to plug and play as we're likely to get. IMHO it is the best
> schema that we have introduced and has helped xAP adoption
considerably.
> Almost every commercial HA software application supports it either
> inbuilt or via plugins. However this prevalence has meant that many
> people try and squeeze every xAP implementation into BSC and hence
> breach it's purpose and capabilities.
>
> Cheers Kevin
>
> On 07/07/2011 11:19, patricklidstone wrote:
> >
> > --- In xAP_developer@xxxxxxx
> <mailto:xAP_developer%40yahoogroups.com>,
"Daniel
> Berenguer"<dberenguer@...> wrote:
> >>> What additional capabilities would you like to see in the
'upper'
> xAP layer?
> >> Not really related to your post. I simply think that having a
good
> schema for M2M apps would be a plus for new adopters. BSC and TSC have
> serious limitations IMO:
> >> http://tech.groups.yahoo.com/group/xAP_developer/message/2120
> >>
> >> If we ever do the jump to the JSON adoption, we may return to
the
> topic.
> >>
> > I have to confess to being a bit of a BSC luddite - most of my
stuff
> predates BSC, and I haven't found an opportunity to use it in anger
> yet, so I don't really feel informed enough to comment on your post.
> >
> > I'd be interested to hear others' opinions on JSON. I really do
find
> the arguments compelling!
> >
> > P.
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>
>
--------------040806040001060100010602
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">
</head>
<body text="#000000" bgcolor="#ffffff">
<!-- **begin egp html banner** -->
<br><br>
<!-- **end egp html banner** -->
I guess there are a number of issues to address, JSON adoption being
perhaps one of them as part of a package to next gen xAP.<br>
<br>
As with all things technology based, things progress. If you were
starting with the proposal of an HA protocol/message structure today
then something that could be parsed automagically, in pretty much
any development environment, would be high on the list of
desirables. So I guess the question is whether xAP should evolve to
xAPJ or something completely new?<br>
<br>
Secondly, if you were working on the assumption of TCP based
networking (and it must be that 99.999% of working implementations
are..), would you use the UDP broadcast mechanism as-is, without
some form of assured delivery? Whilst rare, UDP packet loss, can
cause significant issues when xAP is being used for heating control,
lighting, sprinklers/irrigation, etc., where there is M2M
interaction. Wireless only exacerbates this. So at some level, I
feel, this needs addressing as part of a next generation xAP. <br>
<br>
BSC, hmm. Absolutely one of the greatest strengths, as Kevin says,
and also the Achilles heel in that shoehorning everything into the
schema has broken it and reduced the introduction and adoption of
more relevant ones. In next gen xAP I think this has to be addressed
by being more prescriptive(in many areas) and by a fast track
mechanism for the ratification of new schemas and ideas.<br>
<br>
Which of course comes down to how should any evolution be managed?
Who should manage this? Should there be a committee? An RFC like
process? Should non-standard implementations be 'jumped on', to
maximise long term interoperability? Is there any appetite for this
amongst the developer community?<br>
<br>
Lehane<br>
<br>
<br>
<br>
On 08/07/2011 11:39, Kevin Hawkins wrote:
<blockquote cite="mid:4E16DE7C.4090609@xxxxxxx"
type="cite">
<span style="display: none;"> </span>
<div id="ygrp-text">
<p>I'm fairly enthused with using JSON too, I've been using
it a little in <br>
xAP Flash and now in the iViewer xAP implementation. It
would seem a <br>
good fit for xAP.<br>
<br>
However I feel there are many other aspects of moving xAP
forward that <br>
we need to address, mostly time and commitment related in
order to get <br>
resources and visibility out there. I am not sure we have
that <br>
capability at the moment.<br>
<br>
There are certainly aspects of BSC that we could improve,
a classic <br>
example is how to represent negative values e.g.
temperature for <br>
example. I have posted quite a bit both on and off list
with people <br>
about this, including Daniel, about what we might do here.
There are a <br>
few unofficial BSC enhancements that are in fairly
widespread use <br>
(choice devices and level offsets for example) but no
official BSC2. <br>
TSC I feel is not ready yet for adoption and I know of no
TSC aware <br>
applications.<br>
<br>
BSC is the most widely adopted schema in the xAP world
today and is as <br>
near to plug and play as we're likely to get. IMHO it is
the best <br>
schema that we have introduced and has helped xAP adoption
considerably. <br>
Almost every commercial HA software application supports
it either <br>
inbuilt or via plugins. However this prevalence has meant
that many <br>
people try and squeeze every xAP implementation into BSC
and hence <br>
breach it's purpose and capabilities.<br>
<br>
Cheers Kevin<br>
<br>
On 07/07/2011 11:19, patricklidstone wrote:<br>
><br>
> --- In <a moz-do-not-send="true"
href="mailto:xAP_developer%40yahoogroups.com";>xAP_developer@xxxxxxx</a>,
"Daniel Berenguer"<a class="moz-txt-link-rfc2396E"
href="mailto:dberenguer@...";><dberenguer@...></a>
wrote:<br>
>>> What additional capabilities would you like
to see in the 'upper' xAP layer?<br>
>> Not really related to your post. I simply think
that having a good schema for M2M apps would be a plus for
new adopters. BSC and TSC have serious limitations IMO:<br>
>> <a moz-do-not-send="true"
href="http://tech.groups.yahoo.com/group/xAP_developer/message/2120";>http://tech.groups.yahoo.com/group/xAP_developer/message/2120</a><br>
>><br>
>> If we ever do the jump to the JSON adoption, we
may return to the topic.<br>
>><br>
> I have to confess to being a bit of a BSC luddite -
most of my stuff predates BSC, and I haven't found an
opportunity to use it in anger yet, so I don't really feel
informed enough to comment on your post.<br>
><br>
> I'd be interested to hear others' opinions on JSON. I
really do find the arguments compelling!<br>
><br>
> P.<br>
><br>
><br>
><br>
> ------------------------------------<br>
><br>
> Yahoo! Groups Links<br>
><br>
><br>
><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=2195/stime=1310126530";
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=X3oDMTJmdDZjYWRoBF9TAzk3NDc2NTkwBGdycElkAzk2Mjk0NzYEZ3Jwc3BJZAMxNzA1MDA3NzA5BHNlYwNmdHIEc2xrA3N0bmdzBHN0aW1lAzEzMTAxMjY1MzA-";>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=X3oDMTJkbnJjaWs0BF9TAzk3NDc2NTkwBGdycElkAzk2Mjk0NzYEZ3Jwc3BJZAMxNzA1MDA3NzA5BHNlYwNmdHIEc2xrA2hwZgRzdGltZQMxMzEwMTI2NTMw";>
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>
--------------040806040001060100010602--
xAP_Development Main Index |
xAP_Development Thread Index |
xAP_Development Home |
Archives Home
|