Logger WAS Re: vendor ID reservation

["mark_harrison_uk2" <mph@xxxxxxxxxxxxxxx>]

--- In ukha_xpl@xxxxxxx, steve.cooper@u... wrote:
>
> Mark
>
> I have no experience of xAPLogger but believe it is similar to
> the xPL-VR where all the messages get logged to a database.
> Although I expect that as the logger is used with the intranet
> page it may be more sophisticated in term of data design
> and processing.

Ah - now I know that xPL-VR exists, then I think that I may not need
port logger over :-) I'd not realised it actually existed - mea cupla :-(

In terms of data processing, logger is deliberately an
"ultra-simple"
application that just logs everything (except heartbeats, which in xAP
1.2 don't contain any status info.) The stuff that turns it into an
Intranet page isn't my code - it's James Traynor's.

In terms of database design, then there are three tables in xAPLogger:

- message_header
- message_block
- block_contents

The reason for this down to one of the differences between xAP 1.2 and
xPL - a xAP 1.2 message can contain multiple body parts, each of which
needs to be uniquely identified. I am still very very unsure which was
the right architectural decision - there are some smart syncronisation
things theoretically possible in xAP because of this, but at the
expense of adding a lot of overhead to every message and application
for something that I've personally never needed to do :-)

Were I writing xPLlogger, then I'd use:

- message_header
- message_contents

because there's no need for the extra level of indirection required
and implied by the possibility of multiple message parts. I assume
that this broadly is what xPL-VR does?

In terms of creating "occupancy simulation" via a broadcast
rerun,
then there are some interesting issues to resolve. Should a
"rebroadcaster" resend the identical messages, giving the
original
sender as the "source"? The side-effect of this is that this is
tantamount to "message forging", which may run into issues in the
future. On the other hand, if the "rebroadcaster" gives itself as
the
source, then this potentially gives bogus information in terms of updates.

It may be that some middleground where xPL-CMND messages have a new
source (that of the rebroadcaster) inserted, but xPL-STAT and xPL-TRIG
messages don't. Whether this would be useful rather hinges on whether
there's (now or in the future) much in the way of distributed
intelligence in terms of the ability of other devices to respond
_directly_ in response to telemetry information, rather than only
responding in response to direct commands. If you have the latter,
then you have all the problems of reliance on a single command engine
or the problems of clustering/replicating such a thing to guarantee
functional integrity.

Please don't take any of the above as a criticism of xPL. There's
actually a strong argument that the CMND/STAT/TRIG structure gives
just enough meta-data to be able to resolve these issues in a
system-wide way. By comparison, it's much harder to resolve in xAP 1.2
because of the fact that that particular meta-data item is pushed down
into individual schema or entirely non-deterministic.

Anyway, that's enough long words for one message :-)

Mark