Re: xAP Extended UID (from Some xAP Question)

[Kevin Hawkins <lists@xxxxxxxxxxxxxxxxx>]

g8kmh wrote:
> Clearly extending the UID is required but I'd suggest that it is a
> fixed length and without delimeters. So FFA5000000000001 would be OK.
> Otherwise the effort to parse a UID is going to be pretty close to
> that for a normal V.D.I:SS address format,
>
>
<Here's my thoughts on this...>

The issue is that different developers are seeing the need for different
lengths of identifiers for their implementations - for example IP
address, telephone number, Protocol X , MAC addresses or even say simple
1 wire devices have long unique addresses and the proximity key sensors
have another (really long) ID . We don't want to enforce artificial
restrictions in xAP if possible. The same approach as the source address
flexibility exists in this respect. Having delimiters allows us to
enhance or reduce the address sizing without impacting backward
compatibility should we need to.   The effort to parse a UID is
relatively small, and indeed in most cases people do not process them.
The sub address is the most used part and hence a simple comparison
against : and taking all remaining data is the way.  You do not have all
the issues with wildcarding and the issues of supporting variable length
UID's (ie the v1.2 ones) with implied positional elements and without
delimiters.  I am somewhat open though to moving to a new UID format
(with delimiters) but enforcing the lengths of the positional elements -
for me it isn't a problem once we step beyond the current sub address
limits but there will be others who always need (or want) to use more.
Maybe we should rigidly define a number and see how we go. I do see that
knowing in advance the size of any elements you have to store in an
array is  key. I really don't want however to be facing an IPv6 or a
telephone number reallocation scenario in the future.  Identifying STD,s
Major exchanges ,  sub exchanges, named carriers , local numbers etc
from a UK telephone number is a nightmare - having gone this route in
xAPCID and xAPTEL I couldn't afford that codespace in a xAP embedded
application.

>then one questions why have a UID?
>I'm perhaps being paroichial but in my PIC implementations I'd be
>interested in the UID as a number not as a string.
>Lehane



The UID is of course a hex number - or I guess you mean you don't want
to handle the : and . because you then have to parse it as a string ?
The raison d'etre for the UID I believe you raised before.  The UID is
there for two main reasons.

Firstly it defines a very compact and unique form of the source address.
Given the source address can be very long , and of several hierarchies
this allows devices to recognise other devices uniquely with minimal
address storage space.  For example a light can monitor a switch for an
ONOFF command by storing only 4 bytes currently.  If you are monitoring
several devices with a memory constrained device (small PIC) this space
saving is critical. Even large controllers can make use of this unique
device endpoint identification for their state table arrays.  Such
devices as BSC 'mappers' also use the UID's to map 'event' to 'command'
.It is being considered in the next firmware update for xAP Netiom for
example to include a mapper function, not just for Netiom I/O but for
any device. Having to match long source addresses , and having them
accessible in fast access memory (RAM) would be very restricted by
available space.  The UID also partially serves to offer an enumerated
typeapproach to sub addresses should you so wish .  Note you can't
target UID's as this breaks wildcarding. The xAP C-Bus lighting
controller in my current development version has inbuilt mapping too
using UID's.   The first part of the UID identifies specific networks
and the latter digits make it very apparent when sub addresses are
present and a guide size of the namespace there.

Secondly we have ambitions for within protocol support of Groups and
Scenes where membership is nicely managed by UID's, Although these still
need translating back to source addresses for 'targeting' it is adequate
to store only UID's for 'listening' .  When a controller for example
wants to monitor group (or scene) consistency , or responses to group
commands this provides a fast and compact mechanism.  In limited
capability devices we have discussed that a 'group' or 'scene'
application might proxy this service on behalf of a device and as such
we can create groups/scenes of devices whether they support group
capability or not.  I know some implementation of groups/scenes have
been done at a schema level, including your DMX application and my C-Bus
one.  There are also possibilities in methodologies for groups that may
best be supported using 'aliases' of source addresses.

Kevin

>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>