Re: Changes to Protocol Docs - a Summary

[Gerry Duprey <gerry@xxxxxxxxxxx>]

Howdy,

I, for one, love this.  I think you have absolutely crystallized the
changes
being discussed as of late.

When read this way, summarized as you have, they really don't look that bad
or hard to implement.  #1 & #5 will be in the next xPL4Java release. 
Others
as soon as we decide what to do with them (implement, change or drop).

In my own sort of middle ground, I'm adding a component to the xPL4Java
server that will be available to any other xPL4Java module running under
that server that will keep track of known devices and offer info on them to
to the clients.  I may put a simple xPL face on it too to allow apps that
want to query the list of devices but are not in the frameworks server to
get access. Depending on where these discussion go, it may even make sense
to add a XDCP socket in a future version.

For now, that module will just listen for normal hearbeats and add them.
If/when we hammer out discovery, I'll add that in so that it'll be easier
for other apps to use the module instead of sending the discovery request
themselves, thus lowering the network load and helping to conform to the
"no
more than every 30 seconds" specification.

One note on the discovery mechanism:  Should there be a suggestion that an
xPL app, if it can, should try to introduce a small, optimally random,
delay
before it responds to the request in order to spread out the load on the
network?  I think it's perfectly OK that such a thing would be entirely
optional, but if the developer did want to do it, it would be good if there
were some parameters around how to implement (i.e. no less than 1 second,
no
more than 6 seconds, etc, etc).

Thanks for summarizing this so succinctly Ian!

Gerry


Ian Lowe wrote:
> This is an attempt to summarise the discussions of the last few days -
> if I have misstated anything, please feel free to post a correction. I
> have also dug out a couple of back thoughts from previous discussions
we
> have had that didn't come to anything.
>
> For the record, I am in agreement with everything stated in this
email.
>
> ===============================================================
> 1) Discovery mechanism
>
> It is proposed to add an additional extension of the hbeat.app schema,
> hbeat.request.
>
> The hbeat.basic schema will remain unchanged, and is intended as the
> simplest heartbeat protocol for devices/standalone apps. hbeat.basic
> remains "one way".
>
> hbeat.app will be extended to include hbeat.request - this xpl-cmnd
> message, when received by an application, will cause the application
to
> send a standard heartbeat message.
>
> To avoid the possibility of network congestion, hbeat.request should
not
> be issued more than once in a 30 second period.
>
> ===============================================================
> 2) Rapid Startup
>
> When an application using hbeat.app starts, it will send heartbeat
> messages at a faster rate of 1 per 3 second interval.
>
> When the app recieves it's heartbeat back (indicating that it has
> succesfully joined the xPL network) this will drop to the normal
> heartbeat rate (as specified in the hbeat.app message's
"interval"
> field)
>
> If no succesfull heartbeat has been received (ie, a fault condition
> exists, such as no hub present) the heartbeat rate will drop to a
lower
> rate of 1 per 30 second interval after an initial 90 seconds.
>
>
> ===============================================================
> 3) Device Information
>
> It is proposed that the production of an xml fragment describing a
> vendor's applications is now a required condition of being assigned a
> vendor ID. The XML fragment should describe the various triggers and
> commands that are provided by, or accepted by the applications.
>
> This fragment should contain information for each version of an
> application, where functionality has changed between versions.
>
> To support the use of this information, all heartbeat messages
> (hbeat.basic as well as hbeat.app) should be amended to include a
> "version=" tag. Version numbers should contain only numbers
and the
> decimal point character "."
>
> ===============================================================
> 4) Extended Heartbeat information
>
> Applications using the hbeat.app heartbeat schema may, at the
developers
> option, include additional information tags within the heartbeat
> message. This is supported by the protocol at present, however, where
> this information is provided it *must* be described within the
vendor's
> xml fragment so that this extended information is available to all
> management apps within the xPL network.
>
> ===============================================================
> 5) Case of xPL Message elements
>
> It is proposed that the xPL protocol document be amended to reflect
> common usage - it has been stated on several ocassions that structural
> elements of xPL messages (anything within the header and all
"name="
> elements) should be in lower case only.
>
> At present, this is enforced within the various development frameworks
> but not explicitly stated within the Protocl document.
>
> ===============================================================
>
> How's that for a draft?
>
> Ian.
>
>
>
>
> xPL Links: http://www.xplproject.org.uk http://www.xplhal.com http://www.xpl.myby.co.uk
> To Post a Message: ukha_xpl@xxxxxxx
> To Subscribe:  ukha_xpl-subscribe@xxxxxxx
> To Unsubscribe:  ukha_xpl-unsubscribe@xxxxxxx
> Yahoo! Groups Links
>
>
>
>
>

--
Gerry Duprey
Ann Arbor, MI 48103
http://www.cdp1802.org