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

[Mal Lansell <mal@xxxxxxxxxxx>]

That nice Mr Gates has me brainwashed.  I must take these damn Windows
blinkers off :-(
You are right that the hub shouldn't play a part in this - I can see
that now.

I'll happily vote for the hbeat.request system plus adding the app's
version number to the normal hbeat.

Mal


John B wrote:

> Hi Mal,
>
> > 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.
>
> You're assuming that every app is PC-based.
>
> What about directly connected apps that go straight onto the Ethernet
> network - they don't use a hub, so will never appear in any hub client
> list - likewise RS485 apps, and in fact any other device that doesn't
> use a PC as a host.
>
> > 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?)
>
> I think when we discussed that a long time ago, we agreed that if an
app
> is send-only, there is no need for it to send out heartbeats.
> (but it can if it wants to)
>
> > 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.
>
> I like the idea of using hbeat. As Gerry has already said, hbeat.app
> already permits extra items.
> Adding a version= element would be really straight-forward, and would
> help a lot in debugging.
>
> > 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.
>
> This is where I have to disagree totally!
>
> One of the goals of xPL is to be totally protocol agnostic.
>
> Why do we need hubs? We need them to implement xPL over TCP/IP.
> Hubs are nothing to do with the core protocol - just like mutexes, and
> everything else that's either OS or TCP specific that we've tried to
> avoid.
>
> If we were running xPL devices over something entirely different to
> TCP/IP, we might not need hubs at all.
>
> Therefore, IMO relying on a hub to perform client discovery goes
against
> all the goals of the xPL project.
>
> I don't even like the idea of a hub sending out hbeats and appearing
as
> an xPL device in it's own right - a hub should just sit there silently
> doing it's job.
>
> If we want a faster client discovery than we currently have (which I
> agree is important if client apps are to quickly build up a view of
the
> network) then that should be implemented at the device level.
>
> Gerry's suggestion of a hbeat.request is ideal - all we are asking a
> device to do is respond with it's usual heartbeat whenever it receives
a
> hbeat.request - you can't get much easier than that.
>
> Regards,
>
> John
>
>
> 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
>
>
>
> SPONSORED LINKS
> Protocol analyzer
> <http://groups.yahoo.com/gads?t=ms&k=Protocol+analyzer&w1=Protocol+analyzer&w2=Protocol+converter&w3=Sip+protocol&w4=Tcp&w5=Protocol+analysis&w6=Protocol&c=6&s=111&.sig=QulmGKu5OpHgigyaWFXqqA>
> 	Protocol converter
> <http://groups.yahoo.com/gads?t=ms&k=Protocol+converter&w1=Protocol+analyzer&w2=Protocol+converter&w3=Sip+protocol&w4=Tcp&w5=Protocol+analysis&w6=Protocol&c=6&s=111&.sig=_Gav_2JNLbgwjsCn8RqM-w>
> 	Sip protocol
> <http://groups.yahoo.com/gads?t=ms&k=Sip+protocol&w1=Protocol+analyzer&w2=Protocol+converter&w3=Sip+protocol&w4=Tcp&w5=Protocol+analysis&w6=Protocol&c=6&s=111&.sig=d2G6YVkW-P5WBFmpuWQ3Zw>
>
> Tcp
> <http://groups.yahoo.com/gads?t=ms&k=Tcp&w1=Protocol+analyzer&w2=Protocol+converter&w3=Sip+protocol&w4=Tcp&w5=Protocol+analysis&w6=Protocol&c=6&s=111&.sig=9xqmZjMntiOfVEPLIpwKUg>
> 	Protocol analysis
> <http://groups.yahoo.com/gads?t=ms&k=Protocol+analysis&w1=Protocol+analyzer&w2=Protocol+converter&w3=Sip+protocol&w4=Tcp&w5=Protocol+analysis&w6=Protocol&c=6&s=111&.sig=j5RxaJ5TSW2NTgWhIna4qQ>
> 	Protocol
> <http://groups.yahoo.com/gads?t=ms&k=Protocol&w1=Protocol+analyzer&w2=Protocol+converter&w3=Sip+protocol&w4=Tcp&w5=Protocol+analysis&w6=Protocol&c=6&s=111&.sig=OPnkI6GadMASTgKewyeqDQ>
>
>
>
>
------------------------------------------------------------------------
> 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/>.
>
>
>
------------------------------------------------------------------------
>