RE: Re: xPL announcement/description protocol -- was xPLDiag

["Ian Lowe" <ian.lowe@xxxxxxxxxxxxxxxxxx>]

> As the proverbial beaver.  I'm actually happy as I think that this
reflects a minor
> refinement phase for xPL.

I have to agree! :)

> to participate at the simplest level, all they need to do is add a
little code to watch > for a message (and they can check and just check
the schema class/type if they are super > cramped on space) and spit out
a standard heartbeat (which they already have code to
> do).

My only objection to this one is a simple one - I have a few
applications written that launch, fire a single xpl message, then exit.
They don't even heartbeat! Similarly, I am working on a couple of PIC
situations where they will send an xpl message, but *send only* - there
is no mechanism for these guys to receive, so they can't respond in a
query/respond sense.

Now, for a couple of reasons, I don't want to get into that too deeply
right now, but just keep the door open for device that can only send,
not receive, when considering the implications of extending the hbeat.
schema

> As for triggering the sending of those messages, for that, while I
like the idea about
> hbeat.request (because it so neatly fits into the status request idiom
discussed in the > xPL protocol docs), I could easily support something
else (like about.request or
> about.basic) that caused the heartbeat to be sent.

as above, my concern is tx only apps - if it's a separate schema, which
they don't support, then that's fine.. If, on the other hand, it's the
hbeat schema, and they only implement it partially... I can see that
causing more "huh?" responses later on.

> 1) As you point out, location of the XML files is an issue that has to
solved on every
> platform and especially on platforms like linux, you're going to have
people going ape-
> poopy over whatever choice you make

Indeed... although, I imagine that a link from /etc would be acceptable
to a healthy percentage of users - and of course, there's always the
thing with Linux that anyone who feels strongly about the location of a
set of files... Is free to recompile the code the way they want it!

> 2) Managing those XML files becomes a chore.

One thing as an aside - you *need* to do a write-up on your install
Gerry! It sounds amazing!

As for the point, we have had a similar discussion before - one of the
features xplhal provides is a central list of xPL devices. It's one of
the reasons I keep coming back to it - xplhal is a pretty important part
of the environment, as it provides a hub for configuration/devicde
cache/scripting engine etc.

If we wanted the ultimate cross platform environment, I think we need to
port xplhal to each OS, with XHCP providing a layer of abstraction which
allows any combination of manager/frontend OS to be used with any
combination of backend OS.

When xplhal manager is launched as a frontend, it doesn't have to wait
for a list of devices to build - it gets them from the server.

The concept is the same as WINS in operation - individual devices pop up
one by one, and broadcast their presence, but clients don't need to wait
and listen for everyone to appear - they talk to the WINS/xPLHal server
and get a list instantly.

> 3) I really like the ability of a program, like a front end, to hear
from a device it's > never heard from before, query that device for
info, learn about it and allow some level > of control over it (as long
as it supports a known schema class).

So...

The *server* app (on windows, xplhal) hears from the a new device/app
then queries the xplproject.org.uk repository (or one of the mirrors we
add later on ;)) for the vendor's up to date xml fragment for the app
(this behaviour being configureable, of course)

The front end can either gets it's xml fragments from the server, or
from the internet directly. I'd suggest front end apps would have to be
smart enough to maintain the xml plugin cache on the machine they
operate on - *OR* equally, the dumbest display in the world should be
able to execute a determinator on the local xplhal server(or
equivelant).

> I feel if an app can use them, it should, but it shouldn't be a
requirement (not that
> anyone suggesting it should be a requirement, but).

One thing in that regards - I am kinda suggesting that the production of
an xml fragment is a *requirement* of being a vendor. A developer
building a frontend doesn't have to use them, although they will simlify
the user experience greatly!

> Okay -- but if it at least could respond to an about.basic or
about.request by sending
> out a heartbeat, the initiating application would then be able to
learn it exists and
> then lookup info for it in the appropriate XML file.

What I was mentioning above, really. It's the "respond" thing
that's
making it harder.

> Without that minimal ability (i.e. device discovery), the app/front
end may not hear
> about the device for a long time and if the app is a simple
configuration app or
> similar, it may not typically be run by the end user long enough to
eventually heart
> from all devices.

Which is why you need xplhal ported across all OS platforms - then the
omnipresent server can spot the new app appearing as it fires it's first
heartbeat, and tell the frontend about it.

Ian.