[Message Prev][Message
Next][Thread Prev][Thread Next][Message
Index][Thread Index]
Re: Re: Class naming
--------------080909080200030405020504
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
I'd go with Kevin's suggestion of starting small on a config schema for
getting devices configured, maybe:
Device discovery/Unconfigured device announcement
Device capability
UID renaming
Endpoint renaming
Error reporting (of config)
'Factory reset'! / restore
Security, though I think we shouldn't go overboard on this - 3DES on a
small device may not be doable :-(
I like the idea of a repository (extranet or intranet) template rather
than the device required to provide allowable parameter sets.
I did design a broadcasted device announcement and UID/device renaming
scheme for use on RS485. I didn't require endpoint rename as
switch.1/switch.2 etc worked fine. It was limited in that a rename or
default reset wasn't possible - once you programmed the PIC and put it
on the network then you got one shot at naming. At the small controller
level then options could include schema, jumpers, limited time from
power on or defined input state at power on as some ways to allow a
rename or default reset.
Lehane
estratosapiens wrote:
>
>
> Hi Kevin and Neil,
>
> I've myself tried some workarounds on the config area but nothing to
> do with renaming endpoints. I created a basic schema some time ago for
> bootstrapping controllers but I'll deprecate the schema as soon as
> possible because I've found simpler ways (non xAP) to do the same.
>
> As I explained in a recent post, I prefer to do all the config stuff
> via Web. Configuration is something usually done only once and users
> prefer to do it graphically. Moreover, Most of my dessigns have enough
> horsepower to run a web server so this is less of a problem. On the
> other hand, I admit that some applications could require the
> configuration of "dumb" nodes from other smarter nodes.
Then, I prefer
> Kevin's approach about taking any config parameter as a BSC endpoint.
> As example, let's consider an endpoint renaming:
>
> ...
> class=xAPBSC.cmd
> target=acme.device.instance:myendpoint.name
> ...
> {
> text=newName
> }
>
> And for UID renaming:
>
> ...
> class=xAPBSC.cmd
> target=acme.device.instance:uid
> ...
> {
> text=newUID
> }
>
> This is a very simple approach and would save some code space in your
> controllers. You simply have to manage your config options as any
> other BSC endpoint.
>
> xAP BSC is a very flexible schema. Almost everything can be
> transported and addressed by xAP BSC. Moreover (and maybe the most
> important), it's already implemented in some of the most popular HA
> applications. For instance, if you take the BSC way you'll be able to
> configure/rename your endpoints from Homeseer, Housebot or other xAP
> BSC enabled solutions. Don't underestimate this possibility.
>
> Good luck with your projects and don't hesitate to post any other
> question about xAP or the way to implement xAP in embedded devices.
> I've myself implemented xAP BSC into multiple embedded platforms
> (mainly 32-bit platforms) and I know that some of the discussions
> treated in this forum usually lack the "embedded scope" but
xAP is
> fortunately something flexible (mainly BSC) so you'll find the way to
> adapt your application to its possibilities.
>
> Daniel.
>
> --- In xAP_developer@xxxxxxx
> <mailto:xAP_developer%40yahoogroups.com>,
Kevin Hawkins
> <yahoogroupskh@...> wrote:
> >
> > What I was really meaning is that to use a class name that starts
'xap'
> > it has to be an officially endorsed schema - one that is proven
in
> terms
> > of it's implementation. Early on a few got through fairly easily
> > however :-( For your own class names therefore you mustn't use
xap...
> >
> > In terms of the configuration schema, of which renaming instance
names
> > would logically be one aspect, then indeed it will likely be
named
> > xapconfig but whilst being honed it should appear with a
different name
> > until it all comes together and is formally endorsed. If you look
at
> > the TSC schema document you will see that a similar thing is
happening
> > here and indeed so far it hasn't been included as a xap official
> > schema. A suggestion might just be to use config or xConfig as
the
> > schema name eg config.name config.cmd etc.
> >
> > The official config class should be architected to allow all
aspects of
> > a device to be configured , including recovery of existing
parameter
> > values and prevention of setting illegal or conflicting values. A
> > front end configuration application should, via the schema, be
able to
> > present a user with pertinent information and choices. The schema
> > likely will encompass some form of device discovery and either
> implement
> > UID allocation or work alongside a UID allocation application -
rather
> > like a DHCP server. Aspects of security crop up too. Devices may
need
> > a template that they provide to assist this that might be queried
by
> the
> > schema or held in an internet repository perhaps. We have also
> > discussed electronic schema repositories too. As you can envisage
> > there's quite a few issues to think through and that is partly
why it
> > hasn't been an easy one to tackle. I do expect that BSC will
provide
> > a good basis for this schema , especially if you include the
unofficial
> > 'choice' device type. A range type device will likley be needed
to
> > indicate that an allowable parameter value might be between say
-10 and
> > +212 or requires two decimal places.
> >
> > Having said all the above and probably frightened you a little
with the
> > scope of this configuration schema I think everyone recognises
that we
> > need progress and we should tackle small areas and provided we do
that
> > in a well thought through and architected manner we can evolve
it.
> > Something is better than nothing. Instance naming can be tackled
as a
> > subset provide it implements a flexible mechanism useful for
other
> > aspects of the config schema ie a general parameter
recover/rename
> > model. Likely early on it will remain as a non 'xap' schema
however
> > until we pull the whole xAPconfig schema together.
> >
> > The answer is 'yes' to all the questions in your last paragraph .
There
> > are a couple of people who have tackled this area before and one
in
> > particular I think you should chat with ... I'll get them to
contact
> you
> > either here or offlist.
> >
> > K
> >
> >
> > On 17/03/2010 12:20, Neil Wrightson wrote:
> > >
> > >
> > > Kevin,
> > > Your statement - "You are totally free to add your own
additional
> > > parameters within BSC blocks and to create your own schema
classes
> (as
> > > long as they don't start with the three reserved letters
'xap' as in
> > > xapbsc.cmd) so there's no restriction to what you're trying
to do
> - it
> > > would be just nice to get it adopted in a formalised
way."
> > > Has me puzzled.
> > > From the bible it states "Standard classes can be
identified through
> > > the use of the reserved prefix xap-.... <class>
Identifies the
> > > collection of schema applicable to this message.
<type> Identifies
> the
> > > sub-schema applicable to this message. "
> > > Wouldn't a class that renames instances or end points be a
> standard class?
> > > What restrictions are there on the naming of classes? On the
xAP
> > > wbesite there are lots of schemas that have a class of
xap*****
> > > whatever. I.e. "class = xap-x10.request",
> > > "Class=xAP-INetConnect.Dialup",
"Class=xAP-Audio.Transport"
> > > Given that I'm trying to come up with a way of changing the
instance
> > > name and the end point names. What would you suggest as a
class name
> > > convention that specifically spelt out what the user is to
use?
> > > Do you think that one class should be created for performing
the
> > > renaming of any instance, end point, TSC?
> > > Should it also be cable of changing the UID of the instance?
> > >
> > > Regards,
> > >
> > > *Neil Wrightson.*
> > > */N.W.Electronics/*
> > > ABN 76 768 513 867
> > > Embedded Controllers and Home Automation Products
> > > Skype : Neil_Wrightson
> > > Web :_ www.nwe.net.au_
> > >
> > >
> > >
> > >
> >
>
>
--------------080909080200030405020504
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 bgcolor="#ffffff" text="#000000">
<!-- **begin egp html banner** -->
<br><br>
<!-- **end egp html banner** -->
I'd go with Kevin's suggestion of starting small on a config schema for
getting devices configured, maybe:<br>
<br>
Device discovery/Unconfigured device announcement<br>
Device capability<br>
UID renaming<br>
Endpoint renaming<br>
Error reporting (of config)<br>
'Factory reset'! / restore <br>
Security, though I think we shouldn't go overboard on this - 3DES
on a
small device may not be doable :-(<br>
<br>
I like the idea of a repository (extranet or intranet) template rather
than the device required to provide allowable parameter sets.<br>
<br>
I did design a broadcasted device announcement and UID/device renaming
scheme for use on RS485. I didn't require endpoint rename as
switch.1/switch.2 etc worked fine. It was limited in that a rename or
default reset wasn't possible - once you programmed the PIC and put it
on the network then you got one shot at naming. At the small
controller level then options could include schema, jumpers, limited
time from power on or defined input state at power on as some ways to
allow a rename or default reset.<br>
<br>
Lehane<br>
<br>
<br>
<br>
<br>
<br>
estratosapiens wrote:
<blockquote cite="mid:hnr71b+s55s@xxxxxxx"
type="cite"><span
style="display: none;"> </span>
<div id="ygrp-text">
<p>Hi Kevin and Neil,<br>
<br>
I've myself tried some workarounds on the config area but nothing to do
with renaming endpoints. I created a basic schema some time ago for
bootstrapping controllers but I'll deprecate the schema as soon as
possible because I've found simpler ways (non xAP) to do the
same.<br>
<br>
As I explained in a recent post, I prefer to do all the config stuff
via Web. Configuration is something usually done only once and users
prefer to do it graphically. Moreover, Most of my dessigns have enough
horsepower to run a web server so this is less of a problem. On the
other hand, I admit that some applications could require the
configuration of "dumb" nodes from other smarter nodes. Then, I
prefer
Kevin's approach about taking any config parameter as a BSC endpoint.
As example, let's consider an endpoint renaming:<br>
<br>
...<br>
class=xAPBSC.<wbr>cmd<br>
target=acme.<wbr>device.instance:<wbr>myendpoint.<wbr>name<br>
...<br>
{<br>
text=newName<br>
}<br>
<br>
And for UID renaming:<br>
<br>
...<br>
class=xAPBSC.<wbr>cmd<br>
target=acme.<wbr>device.instance:<wbr>uid<br>
...<br>
{<br>
text=newUID<br>
}<br>
<br>
This is a very simple approach and would save some code space in your
controllers. You simply have to manage your config options as any other
BSC endpoint.<br>
<br>
xAP BSC is a very flexible schema. Almost everything can be transported
and addressed by xAP BSC. Moreover (and maybe the most important), it's
already implemented in some of the most popular HA applications. For
instance, if you take the BSC way you'll be able to configure/rename
your endpoints from Homeseer, Housebot or other xAP BSC enabled
solutions. Don't underestimate this possibility.<br>
<br>
Good luck with your projects and don't hesitate to post any other
question about xAP or the way to implement xAP in embedded devices.
I've myself implemented xAP BSC into multiple embedded platforms
(mainly 32-bit platforms) and I know that some of the discussions
treated in this forum usually lack the "embedded scope" but xAP
is
fortunately something flexible (mainly BSC) so you'll find the way to
adapt your application to its possibilities.<br>
<br>
Daniel.<br>
<br>
--- In <a moz-do-not-send="true"
href="mailto:xAP_developer%40yahoogroups.com";>xAP_developer@<wbr>yahoogroups.<wbr>com</a>,
Kevin Hawkins <yahoogroupskh@<wbr>...> wrote:<br>
><br>
> What I was really meaning is that to use a class name that starts
'xap' <br>
> it has to be an officially endorsed schema - one that is proven in
terms <br>
> of it's implementation. Early on a few got through fairly easily
<br>
> however :-( For your own class names therefore you mustn't use
xap...<br>
> <br>
> In terms of the configuration schema, of which renaming instance
names <br>
> would logically be one aspect, then indeed it will likely be named
<br>
> xapconfig but whilst being honed it should appear with a different
name <br>
> until it all comes together and is formally endorsed. If you look
at <br>
> the TSC schema document you will see that a similar thing is
happening <br>
> here and indeed so far it hasn't been included as a xap official
<br>
> schema. A suggestion might just be to use config or xConfig as the
<br>
> schema name eg config.name config.cmd etc.<br>
> <br>
> The official config class should be architected to allow all
aspects of <br>
> a device to be configured , including recovery of existing
parameter <br>
> values and prevention of setting illegal or conflicting values. A
<br>
> front end configuration application should, via the schema, be
able to <br>
> present a user with pertinent information and choices. The schema
<br>
> likely will encompass some form of device discovery and either
implement <br>
> UID allocation or work alongside a UID allocation application -
rather <br>
> like a DHCP server. Aspects of security crop up too. Devices may
need <br>
> a template that they provide to assist this that might be queried
by the <br>
> schema or held in an internet repository perhaps. We have also
<br>
> discussed electronic schema repositories too. As you can envisage
<br>
> there's quite a few issues to think through and that is partly why
it <br>
> hasn't been an easy one to tackle. I do expect that BSC will
provide <br>
> a good basis for this schema , especially if you include the
unofficial <br>
> 'choice' device type. A range type device will likley be needed to
<br>
> indicate that an allowable parameter value might be between say
-10 and <br>
> +212 or requires two decimal places.<br>
> <br>
> Having said all the above and probably frightened you a little
with the <br>
> scope of this configuration schema I think everyone recognises
that we <br>
> need progress and we should tackle small areas and provided we do
that <br>
> in a well thought through and architected manner we can evolve it.
<br>
> Something is better than nothing. Instance naming can be tackled
as a <br>
> subset provide it implements a flexible mechanism useful for other
<br>
> aspects of the config schema ie a general parameter recover/rename
<br>
> model. Likely early on it will remain as a non 'xap' schema
however <br>
> until we pull the whole xAPconfig schema together.<br>
> <br>
> The answer is 'yes' to all the questions in your last paragraph .
There <br>
> are a couple of people who have tackled this area before and one
in <br>
> particular I think you should chat with ... I'll get them to
contact you <br>
> either here or offlist.<br>
> <br>
> K<br>
> <br>
> <br>
> On 17/03/2010 12:20, Neil Wrightson wrote:<br>
> ><br>
> ><br>
> > Kevin,<br>
> > Your statement - "You are totally free to add your
own
additional <br>
> > parameters within BSC blocks and to create your own
schema
classes (as <br>
> > long as they don't start with the three reserved letters
'xap' as in <br>
> > xapbsc.cmd) so there's no restriction to what you're
trying
to do - it <br>
> > would be just nice to get it adopted in a formalised
way."<br>
> > Has me puzzled.<br>
> > From the bible it states "Standard classes can be
identified
through <br>
> > the use of the reserved prefix xap-....
<class>
Identifies the <br>
> > collection of schema applicable to this message.
<type>
Identifies the <br>
> > sub-schema applicable to this message. "<br>
> > Wouldn't a class that renames instances or end points be
a
standard class?<br>
> > What restrictions are there on the naming of classes? On
the
xAP <br>
> > wbesite there are lots of schemas that have a class of
xap***** <br>
> > whatever. I.e. "class =
xap-x10.request"<wbr>, <br>
> >
"Class=xAP-INetConn<wbr>ect.Dialup"<wbr>,
"Class=xAP-Audio.<wbr>Transport"<br>
> > Given that I'm trying to come up with a way of changing
the
instance <br>
> > name and the end point names. What would you suggest as a
class name <br>
> > convention that specifically spelt out what the user is
to
use?<br>
> > Do you think that one class should be created for
performing
the <br>
> > renaming of any instance, end point, TSC?<br>
> > Should it also be cable of changing the UID of the
instance?<br>
> ><br>
> > Regards,<br>
> ><br>
> > *Neil Wrightson.*<br>
> > */N.W.Electronics/<wbr>*<br>
> > ABN 76 768 513 867<br>
> > Embedded Controllers and Home Automation
Products<br>
> > Skype : Neil_Wrightson<br>
> > Web :_ <a class="moz-txt-link-abbreviated"
href="http://www.nwe.net";>www.nwe.net</a>.<wbr>au_<br>
> ><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=2100/stime=1268886740";
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=X3oDMTJmbTdrYjg1BF9TAzk3NDc2NTkwBGdycElkAzk2Mjk0NzYEZ3Jwc3BJZAMxNzA1MDA3NzA5BHNlYwNmdHIEc2xrA3N0bmdzBHN0aW1lAzEyNjg4ODY3NDA-";>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=X3oDMTJkY2QyYTg3BF9TAzk3NDc2NTkwBGdycElkAzk2Mjk0NzYEZ3Jwc3BJZAMxNzA1MDA3NzA5BHNlYwNmdHIEc2xrA2hwZgRzdGltZQMxMjY4ODg2NzQw";>
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>
--------------080909080200030405020504--
xAP_Development Main Index |
xAP_Development Thread Index |
xAP_Development Home |
Archives Home
|