RE: Re: xAP - The Proposed Architecture Explained - the first extensio

["Mark Harrison" <Mark.Harrison@xxxxxxx>]

OK - an "XML style" key/value pair list.

-----Original Message-----
From: PatrickLidstone [mailto:patrickl@xxxxxxx]
Sent: 14 August 2002 13:51
To: ukha_d@xxxxxxx
Subject: [ukha_d] Re: xAP - The Proposed Architecture Explained - the
first extensio


--- In ukha_d@y..., "Mark Harrison" <Mark.Harrison@e...>
wrote:
> OK - firstly, the idea is that the messages will be in XML, so that
the message structure can be expanded.

Don't do it! XML is fine as a notation to represent the messages but 
the wire format absolutely should not be XML. As I have said before, 
it is not suited for parsing by embedded devices, and is also an 
unnecessary waste of network bandwidth.

> This is good, since I have a fifth, optional item. The IP address 
of the "master bridge". This will be required for WAN
implementations 
where an ethernet-ethernet bridge is being used. It's purpose is to 
obviate the need for globally distinct namespaces, and allow both Mr. 
McCall and I to sit in the same office, both reading messages from a 
HomeVision at home called "Mark".


This assumes there is one bridge. I think there will be more than 1. 
The bridge can be intelligent, introspecting messages. No explicit 
addressing is needed.

I also think you need to review the addressing mechanism. In your 
previous mail you spoke of the input plug-in using specifying the 
output-plugin address. I don't know if this is a typo, or what you 
intenteded, but the input device should simply identify the unique 
data source, nothing more. The output device is then configured to 
listen to a given data source. This is an important and subtle 
distinction.

Imagine that you have a caller id plugin. This plugin is dumb and 
broadcasts just the phone number. You want to display the name of the 
caller too. This requires cascading of plug-ins. The caller-id output 
is picked up by a name/address lookup device and then re-broadcast 
with additional information appended for display.

It is also common-sense to establish some standard HA data types, so 
that all devices represent certain attributes (e.g. temperature) in 
the same way. I would recommend a policy which includes a text device 
status field (for display use etc) and also includes value fields.

e.g. "Outside temp. 31'c"; out_temp_C=31.2

This suggests that messages should have a header + body, with the 
body being hierarchial. It also suggests it might be useful to embed 
some kind of hop-count might be useful. Conveniently this meets most 
of the requirements of a bridging protocol too.

Finally, some thought needs to be given to group addressing or the 
concept that a device might belong to more than one address space. 
Eg. it may be desirable to send messages to all 
displays "downstairs". Where is this mapping maintained? Probably
as 
a service running fault-tolerant on one or more PC's with an LDAP 
backend.

PS. The seetron 20x4 VFD arrived this morning. I have it working, 
connected to a rabbit, with a simple web driven interface. Adding 
broadcast intelligence should be straightforward. The displays are 
nicely made - and the driver software quite intelligent (e.g. auto-
dims if no new message is displayed after given period).




For more information: http://www.automatedhome.co.uk
Post message: ukha_d@xxxxxxx 
Subscribe:  ukha_d-subscribe@xxxxxxx 
Unsubscribe:  ukha_d-unsubscribe@xxxxxxx 
List owner:  ukha_d-owner@xxxxxxx 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/



________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs SkyScan
service. For more information on a proactive anti-virus service working
around the clock, around the globe, visit http://www.messagelabs.com
________________________________________________________________________

Yahoo! Groups Sponsor

ADVERTISEMENT

For more information: http://www.automatedhome.co.uk
Post message: ukha_d@xxxxxxx 
Subscribe:  ukha_d-subscribe@xxxxxxx 
Unsubscribe:  ukha_d-unsubscribe@xxxxxxx 
List owner:  ukha_d-owner@xxxxxxx

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.