Re: xAP/xPL and Rabbits....

["patricklidstone" <patrick@xxxxxxx>]

> For anyone interested, the key differences between xAP and xPL
> (from an xPL point of view, of course) are:

Your perspective differs radically from mine, evidently.

> Broadcast Only vs Broadcast + Directed
> xAP is intended as a broadcast only protocol, with obstacles
against using
> simple messages sent from one device to another for control
purposes.

Not true, xAP supports targetted messaging. Considerable thought has
gone into the xAP addressing structure as a whole; it is elegant,
concise and powerful, and supports all common paradigms (many to one,
one to many, many to many).

>xPL uses messages explicitly directed from one node to another where
required.
>
> Header as Frequently Used Fields vs Header as Addressing Block
> Over several scenarios, it has been reinforced that xAP views the
message
> header as the location to store frequently used fields,
whereas "addressing"
> elements may be contained within either the header, or as message
body
> "class.type" section titles.

Not true, xAP does not support the use of class.type as a means of
addressing.

> Mandatory vs Optional Heartbeats
> xAP applications or devices may elect not to send a heartbeat
packet. Within
> an xPL evironment, every node must generate a regular heartbeat.

This is true, but was included only to allow very low end devices
(those not capable of accurate timing) to join the xAP network. The
recommendation is that all devices support heartbeat generation.

> Variable vs Fixed Field Size
> xAP's design goals call for human legibility within messages. As
such, the
> elements within a xAP message may be of considerable size. xPL
trades some
> of the human readability in return for easier handling of messages
by small
> devices.

The maximum size of a UDP message is limited to 1,500 bytes in any
case...

> Distributed Control vs Central Intelligence
> xAP's initial design goal calls for a fully distributed control,
without a
> central controller.

Not so. xAP is capable of supporting de-centralised control. It is an
option, not a requirement. There is no reason why XPL could not also
be used in this way. That said, decentralised control brings some
significant benefits including graceful degradation.

> Multiple vs Single Message Bodies
> xAP supports multiple message bodies, to allow complex scenes to be
> constructed with a single message. xPL on the other hand, supports
a single
> message body only, instead opting to send a number of simpler
messages to
> different systems.
>
> Heirarchical Message Schemas
> xPL mandates certain basic behaviours from each message class.
Whereas the
> relationship between xAP classes and types remains open to developer
>
> interpretation, all xPL classes must define a .basic message type.
The
> contents and order of the elements within all types belonging to a
given
> class  are inherited from the basic type, allowing developers to
extend the
> types with confidence of compatibility.


Patrick