RE: Pluto

[Kevin Hawkins <lists@xxxxxxxxxxxxxxxxx>]

UKHA wrote:
>
>
> Well, Xap is a 'fat' protocol, xpl is slim - isn;t that one of the
reasons xpl was born?
> You also seem to believe xpl being a 'bastard child' is a bad thing. I
don't.
>
>
> Andy
>
>
Andy - in actuality neither xAP nor xPL are 'fat' or 'thin' - and I'm
surprised anyone who had spent any time looking at either would venture
such an inaccurate comment.

In the overall scheme of things regarding automation protocols on a
scale of 1-100 both must occupy about the 10 mark with the main
difference in xPL being reduced addressing lengths but some additional
layered interactions. However to all essential purposes they occupy
EXACTLY the same ground weight wise .  Binary protocols of a very
customised nature can occupy the lower grounds 1-3 (order of magnitude
smaller) and UPnP /XML etc can take the higher grounds 70+ (order of
magnitude harder). The main goal of xAP (and xPL) was to create a
protocol, readable by humans that was efficient and highly flexible, and
hence expandable. Additionally it had to be adoptable by the typical
'enthusiast' programmer,  and to all intents and purposes both address
these needs.   Inevitably to expand on features you either increase the
weight of the protocol or you become more 'cryptic' in its core nature ,
your choice but one is counter to the other and xAP and xPL have
differing views.  Any human readable protocol can never be a lightweight
or highly efficient protocol in 'computer speak'. So xAP and xPL occupy
exactly the same seat essentially.

xAP and xPL still lack  by not offering the 'complete' range of schema
that we would like to flush out the specification but achieving that is
an awesome task and requires the protocol to snowball and involve many
contributors. UPnP attempts this and has thousands of people in tens of
committees , many who actually get paid to develop such things and yet
still has very few such offerings to date, (and even then end up
manufacturer specific as in the AV schema)   so not surprisingly in xAP
and xPL this is still a.'todo'   The beauty of xAP and xPL is that it is
just really easy to create your own ....

This was always my bugbear with xPL - that it 'pinched' all the hard
work that gone into xAP and fragmented it whilst it was too early in its
infancy. xPL additionally was created to solve the needs of the
developers in their own setups and didn't aspire as a protocol suitable
for many, either in its definition, or its marketing .  As such we
halved, duplicated and confused the effort that we could have had to get
that snowball rolling and we risk neither achieving what could have
been. ..    By both being there perhaps neither can grow .    Anyone can
argue the pro's and con's of xAP vs XPL but it's really a comparison of
'Golden Delicious' and  'Granny Smiths'  ie just flavours of the same
things - essentially both as capable and addressing a taste
preference.   The bottom line is that there is a need  for a protocol
that allows moderately technical people (hobbyist programmers) to get
their bits and bobs talking to each other in real time and to
effectively create no ceilings to such automated control.  There's also
a need for an end user solution but that's a way off still. xAP has
allowed me to achieve automation in my home and I'm sure xPL has done
likewise for many too  Am I prepared to champion xAP as a solution for
everyone - No .... because as a solution for non technical 'end users'
neither xAP nor xPL can deliver yet - whereas for semi technical users
it's an enabler and an architecture allowing me to build - yes, it needs
an investment in understanding but it rewards that with a 'of course you
can' which works for me.....


Kevin