Re: Proposal / RFC: Change xAP wire format

["Daniel Berenguer" <dberenguer@xxxxxxxxxxxx>]

Hi Alan,

Having myself integrated xAP (BSC) on several computing platforms, I must
say that xAP is maybe not the most compact protocol for very constrained
uC's. On the other hand, even if xAP wanted to be network-agnostic, the
fact is that xAP is specially suited for IP networks. I'd never recommend
the use of xAP on RS485 buses for example (this is my personal opinion). As
result, people is usually adding xAP capabilities on IP-capable uC's only.
This said, IP-capable platforms usually have the necessary resources to run
a basic xAP stack without problems so adding JSON or not shouldn't be an
issue.

Daniel.



--- In xAP_developer@xxxxxxx, "hillbillies@..."
<hillbillies@...> wrote:
>
> Hi Patrick,
>
> I know that this is an old thread but I have been thinking about
posting on this for a little while. Having been woken up at 4:11 this
morning by an aftershock (that's what happens when you live in
Christchurch, NZ!) I've had plenty of time to put my ideas together. I'm
new to xAP, only been playing around for a couple of months on AVR devices
and I don't have a full system running yet.
> I don't want to put down any of the ideas of those that have been in
the project for a long time, but I think that I can put forward some ideas
from a different perspective.
>
> Background:
> I wanted to monitor my power meter to look at energy consumption. If I
was putting some wires in for that I might as well have a play with home
automation. I looked around and liked the ideas of xAP, specifically that
is was non-centralised and it was agnostic of processor and network. It is
nice that a fair amount of work has been put into Linux app which I wanted
to use.
> I decided to go with the idea of putting the full xAP message over an
RS485 2 wire link using J1708 style circuitry. Over the last month I've put
together a library for the AVR for carrier sense multiple access with
collision detection. I wanted a low power network (which is why I didn't go
for ethernet) and to keep things simple. The idea for putting the full xAP
message over the network (rather than the BAZ485 idea) was that it is just
an extension of the UDP network, rather than a load of sensors attached to
the PC.
>
> So coming from an embedded point of view I would like to put forward
some points on your idea for a wire format change:
>
> On the main front page of the xAP website it says:
>
> -Simple, easy to implement/retrofit
> -Suitable for use with a wide range of processing capabilities, from
embedded controllers to fully fledged PC's
> -Operating system agnostic
> -Programming language agnostic
> -Network agnostic
>
> Where to you see xAP going?
>
> From what I can see most of the development has gone into PC centric
UDP messaging applications. I'm coming from a different point of view, the
embedded world.
>
> What I do like is the human readable message, I've got to say that
it's helped me alot in my development. However in the embedded world with
the lack of RAM and processing cycles the passing of redundant data is a
waste.
> If you look at the JSON protocol there can be white spaces and plenty
of double-quote symbols. What's the point of sending this information? It's
OK in a UDP packet on a PC. But if you want to be network agnostic then you
need to cater for lower bandwidths. I would be in favor of taking the
existing 'source=' and turning it into 's='. We know what source is
mandatory, it's got to be there, the 'ource' is redundant data.
>
> By reducing the amount of data sent across the link you are benefiting
from:
> - Less RAM used to hold it while processing
> - Reduced processing time to decode the packet
> - Less time on the physical network (therefore increase the number of
packets you can put across)
>
> As I said before, where does the group see xAP going. If it wants to
move forward in the lower power, lower speed embedded world then maybe JSON
is not the right way to go?
> If xAP's future is x86/ARM then it's not a problem, but I guess that
the protocol has to suit the lowest common denominator. A high speed
processor can cope with JSON or any other protocol that is thrown at it, a
low spec processor can only cope with simple things.
>
> What are other peoples views on this - I'm ready to be shot down.
> Like I said earlier, I'm new to xAP and I want to thank people for
their development efforts. I'm not trying to push my thoughts, just airing
them in public.
>
> Cheers
>
> Alan
>
> --- In xAP_developer@xxxxxxx, "patricklidstone"
<patrick@> wrote:
> >
> > I would like to propose a fundamental change to xAP - adopting
JSON notation for the wireformat. JSON (RFC4627 / http://en.wikipedia.org/wiki/JSON
/ json.org for further details) is now an established standard, with wide
cross-platform and cross-language support.
> >
> > A wide array of parsers are available off-the-shelf. It is very
similar to the existing wireformat, which pre-dates JSON, and the JSON
manifesto incorporates many of the design aims of the original format (such
as XML being too complex/too fat for optimal use on embedded devices).
> >
> > Whilst retrofitting support to existing apps would be slightly
painful, the fact that most libraries and frameworks abstract the parsing,
and that there are inherent similarities, wouldn't make the switch too bad
from a developer perspective, and that burden is outweighed by the adoption
of a standard IMO.
> >
> > Thoughts?
> >
> > Patrick
> >
>




------------------------------------