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

[Mal Lansell <mal@xxxxxxxxxxx>]

Perhaps the key to all of this is the hub's client list.  With the rapid
heartbeat system leading to quick discovery, the client list will be up
to date.  Querying the hubs for client details should prove a sufficient
starting point for a front end or diag tool to construct a list of xPL
apps.

There is still the problem of your send-only devices, but to be honest I
don't see any way to include those.  If they can't receive, then they
can't respond to requests or implement a rapid heartbeat system - they
will just have to be discovered when they transmit (in fact, was there
ever any reason for a send-only device to send hbeats? They are only
there to tell the hub it needs to send you messages, but if you can't
receive them, what's the point?)

In my proposal for about.basic there was only one item that could not go
into the vendor xml - the application version number.  Perhaps rather
than create a new schema, the hbeat messages sent by new apps can add a
version=... item to the end.  This could be stored by the hub in its
client list, and returned as part of a hub query.  This is backwards
compatible, since older apps will still be reported, just without a
version number.

Now for the query itself.  This *will* require a new schema.  The
request is broadcast in the usual manner, but instead of being
retransmitted, the hub responds directly to the ip and port listed in
the request, even if it is not local.  This ensures that the requesting
app receives details of the whole network, and not just the local
machine.  The hub may need to send more than one message if the client
list is so long that the message will be too large.

The requesting application would build it's initial app list from all
the responses, and from then on would maintain it by monitoring hbeats
in the same way that the hub does.

The messages would look something like this:

xpl-cmnd
{
hop=1
source=mal-xpldiag.default
target=*
}
hub.basic
{
remote-ip="192.168.0.4"   //IP and port to send client list to
port="50002"
}

Hub response:

xpl-stat
{
hop=1
source=vendor-device.instance    // this is dummy info - hubs do not
have these items.
target=*
}
hub.basic
{
client="[vendor-device.instance],[ip],[port],[version],[time until
next
hbeat in seconds]"
client="..."
...
client="..."
}

Purists may cry foul at the idea of hubs sending their own xPL messages,
but it would be better to use a method that we know is working than try
to open a new port with all the firewall etc issues to go through again.

Mal



Ian Lowe wrote:

> > 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.
>
>
> 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
>
>     *  Visit your group "ukha_xpl
>       <http://groups.yahoo.com/group/ukha_xpl>"
on the web.
>
>     *  To unsubscribe from this group, send an email to:
>        ukha_xpl-unsubscribe@xxxxxxx
>       <mailto:ukha_xpl-unsubscribe@xxxxxxx?subject=Unsubscribe>
>
>     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>
>
------------------------------------------------------------------------
>