[Message Prev][Message
Next][Thread Prev][Thread Next][Message
Index][Thread Index]
Re: Proposal / RFC: Change xAP wire format
- Subject: Re: Proposal / RFC: Change xAP wire format
- From: "patricklidstone" <patrick@xxxxxxxxxxxx>
- Date: Mon, 12 Dec 2011 13:45:05 -0000
--- 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
>
Hi Alan,
What you describe is exactly the ethos that I had in mind when xAP was
conceived, and the concepts that I stood up when debates raged around the
establishment of the original standard.
I guess my thoughts around JSON were - perhaps it represented a happy
medium between bloaty XML which is completely embedded-unfriendly and the
perceived "proprietary" nature of xAP. And that by perhaps
adopting/shoe horning an open standard into the equation, we'd give xAP a
bit of a shot in the arm.
In retrospect, perhaps that was wrong, and that we shouldn't be ashamed of
the fact that xAP has got an awful lot right from the outset. It's not 100%
perfect; it was never intended to be a universal tool for every use case,
but it does do what it does really rather well, and the fact that I am
getting emails about code I wrote the best part of 6 years later is an
endorsement of that.
Perhaps it isn't broken and doesn't need fixing :-) ?
Patrick
------------------------------------
xAP_Development Main Index |
xAP_Development Thread Index |
xAP_Development Home |
Archives Home
|