Re: Changes to Protocol Docs - a Summary

[Mal Lansell <mal@xxxxxxxxxxx>]

Ian Lowe wrote:

> > My votes:
> > 1- No. I am not convinced this belongs in the xpl network.
>
> Ahh go on...
>
> I didn't think so either, but I am convinced by just thinking through
> how useful it would be. (this is actually code - when I was explaining
> the current discussions to my wife she said "about bloody time -
waiting
> for devices to appear in the manager is a complete pain in the
t*ts" -
> user feedback ;)
>
You lucky man.  My wife likes gadgets, but I don't think she would want
to go anywhere near xPLHal Manager :-)

> > 3- No. If you need that information examine the properties of the
> application or consult > the readme or use a (future) diagnostic
tool -
> but again, this is not part of the xpl
> > network imo.
>
> Well... The xml fragment is already pretty much needed - adding the
app
> version? It's pretty basic info.
>
And pretty useful too - the xmls are per vendor, not per application, so
they cannot reflect which version of a particular app is installed.

> > 5- No. If we would start from scratch I would definitely vote yes
on
> this one, but
> > alas... many applications use a mixture of lower and upper case
in
> their messages. Maybe > we should go in the other sense instead and
make
> xPL case insensitive.
>
> Actually... They don't. anything written using xpllib or the xPL OCX
are
> forced to lower case automagically. This one is really just
formalising
> existing practice.
>
> The reasoning - case insensitive is a complete pain in the ass for
small
> devices - it adds a lot of parsing that doesn't need to be there. And
> remember, we are talking about the message structure elements only,
not
> the actual content of messages.

And to think I got a telling off last week because my hub was
lowercasing all the messages as they went through - sounds like I should
put that "feature" back in :-)

Mal