Re: Proposal for VSCP schema

[Gregg Liming <gregg@xxxxxxxxxxx>]

YAP wrote:

>>(1) I notice that you don't align VSCP classes
>>=20=20=20=20
>>
>
>My thinking was that they are so different that it would not make any
>sense. for incoming VSCP events. But sure a construct like
>
>vscp.event."vscp-class"."vscp.type"=20=20
>
>would work equally well. Would this be acceptable and prefered?
>
>=20=20
>
From my perspective, just the vscp-class is needed--mostly because each=20
vscp class defines a functionally distinct set of messages (which IMO=20
map well to the notion of a distinct schema).  And, VSCP
"handlers"=20
would be developed incrementally to handle these different classes=20
(since they map into a totally different set of semantics and behaviors).

>>(2) Will you be supporting VSCP class=3D0 messages?=20
>>=20=20=20=20
>>
>Class=3D0 is the only class that have some events that address nodes.
>The current version of the daemon interfaces does not support this and
>the upcoming release will not either but the release after that will.
>
>To do this the Interfaces that the device is at has to be known. So
>the magic number form my previous post "6789" is the
interface id and
>would address the correct interface.
>
>This is just a problem for Level I devices which use the nickname id
>instead of the bandwidth wasting full GUID used on Level II.
>
>=20=20
>
>>VSCP daemon hearbeats...
>>=20=20=20=20
>>
>VSCP nodes can send heartbeats but normally they want do that. Instead
>a temperature node sends out the temperature and so on.=20
>
...which presumably could be functionally equivalent to a heart-beat (to=20
indicate that the temperature node is still "alive") assuming
that the=20
messages are output at periodic intervals regardless of a change in=20
temperature (which to me is an "event").

>So any
>heartbeats from VSCP nodes will come out to xAP just as a any standard
>VSCP event. I will however implement the standard hearbeat in the xAP
>VSCP daemon driver and allow for mapping if someone wants this.
>
>=20=20
>
That would be good so that we know that "no news" can actually
be=20
considered "good news" ;)

>Some qustions coming up on my side.
>
>For UID=3DFF123400
>
>how are the 1234 assigned uniquely. Manually or through some automatic
pro=
cess?
>
>=20=20
>
Kevin or others are better suited to answer this "officially". 
I=20
manually pick a default that I hope is not anyone elses.  I also allow=20
an override via config parms.  I "auto" assign the "00"
as the devices=20
are "registered" w/ the mh implementation.  That means (for me),
that=20
the subaddress part of the UID is consistently assigned but not=20
externally predictable (which can not occur until the UID field gets a=20
lot bigger).  I don't permit overrides on the subaddress UID assignment=20
(as it occurs automatically).

>For the xAP hubs that are available today is there a standard way to
>detect that a HUB is already there so my code can select if it should
>be a client or start its own HUB functionality?
>=20=20
>
In mh, it works like this...
1) The user can control whether mh implements a hub or not.
2) If the user wants mh to implement a hub, mh will attempt to bind to=20
the hub port.  If it can't, then it will "downgrade" to no hub=20
operation.  It will not continue trying (but will output
"nastygrams" to=20
the log).
3) Mh always assumes that some hub exists to support hub operation and=20
binds to the first available ephemeral port.  It sends out heart-beats=20
so that the local hub knows what port it is listening on.

IMO, implementing a hub is a convenience (for users) and by no means a=20
necessity.  Personally, I prefer to run them as a separate process so=20
that their operations don't arbitrarily block the application.

Gregg