Re: Re: Proposal for VSCP schema

[YAP <x112358@xxxxxxxxx>]

An update on this

I have done a first xAP driver for the CANAL/VSCP daemon on the WIN32
platform. It should work either as a client to an existing HUB or as a
HUB by it self. The Linux/Unix version will follow but I have some
other this to do before I can do that.

Currently the driver is available through the VSCP CVS but will be
included in the next release of VSCP and Friends.

The schema used is here http://www.vscp.org/wiki/doku.php?id=3Dvscp_xap_sch=
ema

Regards
/Ake


On 8/8/05, g8kmh <g8kmh@xxxxxxx> wrote:
>  As one of the potential abusers :-)
>=20=20
>  Either of the two UID address forms is fine with me, although the=20
>  longer form would seem to have some long term advantages and there
is=20
>  little difference in processing overhead or packet size.
>=20=20
>  Lehane
>=20=20
>=20=20
>  --- In xAP_developer@xxxxxxx, Kevin Hawkins <lists@u...>=20
>=20
>  wrote:
>  > Mark Harrison (Groups) wrote:
>  >=20
>  > >On Mon, 2005-08-08 at 08:14 -0400, Gregg Liming wrote:
>  > >=20=20
>  > >
>  > >>This limitation is (IMO) very limiting to those of us
creating=20
>  xAP=20
>  > >>gateways for systems that have many more than 254
devices and
>  > >>inevitably=20
>  > >>causes "hacks" to be required to handle the
mappings.  I'm=20
>  personally=20
>  > >>hoping that the xAP spec will be revised soon to support
a much=20
>  larger
>  > >>number of subaddresses.  In the mean time, I've had to
resort to=20
>  > >>"virtual" subaddresses that nominally map to
semi-natural=20
>  groupings of
>  > >>devices.  Even this technique, however, doesn't scale
well and=20
>  will=20
>  > >>break if pushed.
>  > >>=20=20=20=20
>  > >>
>  > >
>  > >We discussed this at xAPCon04, and ISTR that everyone was
in=20
>  favour of
>  > >extending the size of UID.
>  > >
>  > >I note that Kevin is going to push this forward, though for
the=20
>  record,
>  > >my preference is for 2N8A8S
>  > >=20=20
>  > >
>  >=20
>  > and mine....  :-)      although I sort of like including the=20
>  delimiters=20
>  > - but no-one else did so I'll surrender !
>  >=20
>  > >That having been said, I'm in favour of the "majority
decision" on=20
>  which
>  > >length they should be because a quick decision is more
important=20
>  to me
>  > >than the difference between 2N8A8S and 2N6A6S - either is
enough=20
>  for the
>  > >immediate requirements.
>  > >
>  > >If nothing else, it would make the BSC handling in
xAPHomeVision=20
>  _much_
>  > >easier - at the moment, we map each house code on to a
different=20
>  xAP
>  > >Device, to allow the full 256 X-10 devices - the 254 limit
was=20
>  terribly
>  > >annoying. (I realise that xAPHomeSeer has a different set of
>  > >constraints, because of the way that HomeSeer allows virtual
X-10
>  > >devices.)
>  > >
>  > >If truth be told, the BSC Support in xAPHomeVision is good,
but=20
>  the X-10
>  > >Schema support is fairly flakey. I'd be in favour of getting
the=20
>  UID
>  > >issue resolved ASAP, so we can rewrite the X-10 stuff
cleanly!
>  > >
>  > >One key question though - will extended UID be enough to
push v=3D12=
=20
>  up to
>  > >v=3D13? I think, realistically, yes, in which case we may
want to=20
>  consider
>  > >message fragmentation at the same time - though the
"get it done"=20
>  rule
>  > >is again more important to me.
>  > >=20=20
>  > >
>  > I think I would like to formally agree the format of the new
UID=20
>  and=20
>  > release it asap so that people can use it from effectively xAP
1.21=20
>  > onwards.  I would very much like to get the message
sequencing=20
>  ironed=20
>  > out (and those couple of other things that build on this that
we=20
>  > discussed at xAPCon) but I think there's still a bit of work to
do=20
>  here=20
>  > and I wouldn't want to delay the UID adoption as it's
impacting=20
>  lots of=20
>  > applications and even causing 'abuse' of the UID as there isn't
an=20
>  > alternative.  AFAIK the UID change is the only aspect that
could=20
>  cause=20
>  > incompatability with existing applications - the other changes
are=20
>  all=20
>  > really enhancements that work as higher level policies and so=20
>  should be=20
>  > transparent.  (remember "gracefully ignore any
unexpected=20
>  parameters you=20
>  > don't recognise/expect whilst parsing", including within
the=20
>  header).=20=20
>  > BTW Gracefully means "don't throw a wobbly" and don't
drop=20
>  subseqent=20
>  > parsing.
>  >=20
>  > >M.
>  > >
>  > >=20=20
>  > >
>  > K
>=20=20
>=20=20
>=20=20
>=20=20
>=20=20
>=20=20
>=20=20
>=20=20
>=20=20
>  ________________________________
>  YAHOO! GROUPS LINKS=20
>=20=20
>=20=20
>  Visit your group "xAP_developer" on the web.
>=20=20=20
>  To unsubscribe from this group, send an email to:
>  xAP_developer-unsubscribe@xxxxxxx
>=20=20=20
>  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service.=20
>=20=20
>  ________________________________
>