[Message Prev][Message
Next][Thread Prev][Thread Next][Message
Index][Thread Index]
Re: Proposal for VSCP schema
Mark Harrison (Groups) wrote:
>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
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 personally=20
>>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=20
>>"virtual" subaddresses that nominally map to semi-natural
groupings of
>>devices. Even this technique, however, doesn't scale well and
will=20
>>break if pushed.
>>=20=20=20=20
>>
>
>We discussed this at xAPCon04, and ISTR that everyone was in favour of
>extending the size of UID.
>
>I note that Kevin is going to push this forward, though for the record,
>my preference is for 2N8A8S
>=20=20
>
and mine.... :-) although I sort of like including the delimiters=20
- but no-one else did so I'll surrender !
>That having been said, I'm in favour of the "majority
decision" on which
>length they should be because a quick decision is more important to me
>than the difference between 2N8A8S and 2N6A6S - either is enough for
the
>immediate requirements.
>
>If nothing else, it would make the BSC handling in xAPHomeVision _much_
>easier - at the moment, we map each house code on to a different xAP
>Device, to allow the full 256 X-10 devices - the 254 limit was 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 the
X-10
>Schema support is fairly flakey. I'd be in favour of getting the 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 up
to
>v=3D13? I think, realistically, yes, in which case we may want to
consider
>message fragmentation at the same time - though the "get it
done" rule
>is again more important to me.
>=20=20
>
I think I would like to formally agree the format of the new UID 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 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 here=20
and I wouldn't want to delay the UID adoption as it's impacting 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 cause=20
incompatability with existing applications - the other changes are all=20
really enhancements that work as higher level policies and so should be=20
transparent. (remember "gracefully ignore any unexpected parameters
you=20
don't recognise/expect whilst parsing", including within the
header).=20=20
BTW Gracefully means "don't throw a wobbly" and don't drop
subseqent=20
parsing.
>M.
>
>=20=20
>
K
xAP_Development Main Index |
xAP_Development Thread Index |
xAP_Development Home |
Archives Home
|