Re: Class naming

["estratosapiens" <dberenguer@xxxxxxxxxxxx>]

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, 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_
> >
> >
> >
> >
>




------------------------------------