Re: Proposal for VSCP schema

[Kevin Hawkins <lists@xxxxxxxxxxxxxxxxx>]

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.
>
>/Ake
>
>
>
Hi Ake

Just read your RFC on the train, good stuff,  and I have just been
beaten to the post via Greg who has raised a lot of the points (and many
others) that I was going to make.

Just recapping on a couple of the key ones. A xAP longform address (
source= ) is made up of two parts , the application/device address and
then a ':' and then a sub address which is intended for further
segmented endpoints within that one device.   The whole address must
uniquely map to a UID of the form  NNAAAASS   where NN is the network
(usualy FF), AAA is the application/device ie the main address to the
left of the : in the source= part and the SS is the sub address.  00 and
FF are reserved for SS and so you have 254 possible sub addresses to
play with.   00 is used to identify the complete device rather than any
individual enpoint and FF is reserved for future use.  What is important
is that any source address must map to a specific and unique UID and
each possible sub address (the part after the : ) must map to 01-FE as
the last two digits of a UID   Hence no soure addresses with a : in them
can have a UID that ends in 00.

This 254 limit on sub addresses is restrictive, we are aware of that
and will be expanding the UID soon, indeed I will again canvas the
steering group to get this formalised & released ASAP.  It is likley to
move to the form NNAAAAAASSSSSS or NNAAAAAAAASSSSSSSS  which will be a
vast improvement. People writing current applications should make
provision for this.  If anyone has any comments on this sizing please
let me know. We are potentially interested in how this might be used to
map to other specific unique identifiers eg MAC addresses, IP or
GUID's.     We have also considered but dismissed a separator in the UID
as a delimiter ie UID=NN-AAAA-SSSS  to allow variable length allocations.

In your VSCP class within xAP I think you should have a different
class or block identifier for a received VSCP compared with  a command
to send one, otherwise they can't be differentiated (except by teh
inference that there is a target line present).  So I would suggest
something like

Class=VSCP with a block of level1.event  and level1.cmd or perhaps
Class=VSCP.event / Class=VSCP.cmd  with a  block name of just level1
perhaps

(duplicating VSCP and the level1 in both the class and section name
isn't necessary and uses space.   The Class should identify the types of
possible messages (blocks) that you might expect (ie the schema) and the
blocknames define the actual type of data content to be expected within
the block so perhaps level1 and later level2 are both subsets of a
VSCP.cmd or VSCP.event


Where you are using ASCII coded hex data - if it really is binary data
(and I think it is from the VSCP spec) then you should use the ! (pling)
delimiter instead of the =
ie data!010701  rather than data=010701 - its is then known it can be
stored in 3 bytes.

I am confused by the source/target address formation in the BSC mapping
but I need to refer back to the VSCP to better understand this I
think....  basically I think it's a way of mapping an address of teh
form 0-255 on VSCP to a longform address in xAP.   Certainly they map
well if you can avoid the 00 and FF addresses on level1 VSCP - but you
may need to handle wildcarding with some care (or ignore it) , by
generating multiple messages on VSCP possibly.

More thoughts poss later... looks a good basis to work from though

Kevin

PS Are there any level2 VSCP devices about yet ??