Re: Re: Proposal / RFC: Change xAP wire format

[Kevin Hawkins <yahoogroupskh@xxxxxxxxxxxxxx>]

Actually there have been several implementations of xAP on low
bandwidth
networks but I agree it's not ideal / the most compact protocol, human
readability precludes it. The lower the bus speed and the higher the
traffic  the bigger the problem.    There are a host of really compact
alternative protocols but they of course sacrifice some of xAP's
features like readability , wildcard addressing etc.   If your bus is
part of a wider bandwidth xAP topology eg Ethernet and it is an 'end of
the road' in terms of xAP traffic then you do have options to minimise
bandwidth.

You could for example :

Tokenise or even 'drop' some of the xAP parameter names .

Implement a bridge that filters traffic such that only relevant packets
are passed onto the low bandwidth segment.

In your bridge you could bi-directionally map longer source names to
shortform addresses - but your bridge would have to manage wildcard
matching.   Wildcard matchingwithin the low speed segment wouldn't be
impacted.

Using these techniques you can get a very satisfactory implementation
whilst retaining interoperability with other xAP devices on say
Ethernet.  IIRC both Patrick and Lehane have implemented xAP over RS-485.

If you are totally standalone then you could use significantly compacted
source addresses and not use wildcarding at all, plus tokenise / omit
parameters.  It's really only when you're bridging into a wider world
and need interoperability that you need to be careful and then you can
implement a lot of smarts in the bridge.  OTOH if you are totally
standalone and low bandwidth then I am not sure xAP is a sensible
choice...or what advantage it would offer, or why you would consider it
anyway.... !

JSON really offers no benefit for low speed devices so it's a bit of a
red herring in that respect.   What's good is that embedded devices are
becoming faster, larger in capacity  and lower in cost so this is a
diminishing problem...    It would be neat to be able to implement xAP
on a $5 device though.

K


On 30/11/2011 18:25, Daniel Berenguer wrote:
> 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
>>>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>



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