Re: Proposal for VSCP schema

[Gregg Liming <gregg@xxxxxxxxxxx>]

YAP wrote:

>Hi,
>
>This is a RFC as I have written up a first proposal for a VSCP schema
>and some initial VSCP-xAP mapping thoughts. It is available on this
>page http://www.vscp.org/vscp/proposals
>
>Suggestions, thoughts, directions are all welcome.
>
Hi Ake,

A couple of comments:

1) Your "received message" (re:
http://www.vscp.org/vscp/proposals/VSCP%20xAP%20Schema%20examples.html)
does not contain a nickname field---which your schema (re:
http://www.vscp.org/vscp/proposals/VSCP%20xAP%20Schema.html)
claims is
mandatory

2) I am confused by the statement "6789 is an optional interface
channel
on the daemon" w/i your first example.  Is "interface
channel" the same
as the actual device or is it some transport/medium for gaining access
to the device?  If the latter, then (AFAIK) the xAP subaddress needs to
be fully qualified (i.e., include the device reference).

3) It is not clear to me the relationship/mapping between VSCP level 1
nicknames and your xAP subaddress.  Logically, they might be identical.

4) The selection of "1234" in your UID is probably a bad default
value.
I'm assuming that your daemon will have some ability to permit the user
to init this portion of the UID to something else.

5) The LSBs "00" in your UID need to be changed to the mapped
subaddress
UID values that correspond to your "6789" subaddress.

6) From my limited reading of the VSCP spec, a level 1 VSCP segment can
support up to 256 level 1 devices.  The maximum xAP subaddress range is
254.  This means that a base xAP address of eurosrc.vscp.zeus could map
to at most a single level 1 VSCP segment--excepting 2 of the possible
256 devices.  The implication is that you will need more xAP base
addresses to map to other segments (if that's needed) and groupings of
level 2 VSCP devices.

This limitation is (IMO) very limiting to those of us creating xAP
gateways for systems that have many more than 254 devices and inevitably
causes "hacks" to be required to handle the mappings.  I'm
personally
hoping that the xAP spec will be revised soon to support a much larger
number of subaddresses.  In the mean time, I've had to resort to
"virtual" subaddresses that nominally map to semi-natural
groupings of
devices.  Even this technique, however, doesn't scale well and will
break if pushed.

7) Your BSC example
(http://www.vscp.org/vscp/proposals/VSCP%20xAP%20mapping.html)
shows an
xAP address of eurosrc.vscp.bsc.idx.zone.subzone*.*  I would have
expected use of xAP subaddressing syntax instead like:

eurosrc.vscp.bsc:idx.zone.subzone

Admittedly, I'm still confused by the use of idx and the absence of a
device reference following subzone.  Also, is "bsc"
useful/appropriate
in an address (it's obvious that bsc is being used based on the xAP
class value)?

Regards,

Gregg