The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024


[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

Re: xPL announcement/description protocol -- was xPLDiag


  • Subject: Re: xPL announcement/description protocol -- was xPLDiag
  • From: "Mal Lansell" <mal@xxxxxxxxxxx>
  • Date: Fri, 23 Sep 2005 10:24:29 -0000

--- In ukha_xpl@xxxxxxx, "Tony Tofts" <tony@x> wrote:
>
> > I don't see how that would make anything more robust - if the
> > client exits before the hub, which may well happen when the
> > system is shut down, it still gets deleted from the list.
>
> I mis-wrote what I meant, what I mean't was for the hub to retain
the list
> of clients that hadn't expired at shutdown, even if they had sent a
> hbeat.end (i.e. if hub closes before expiry of an ended app it
starts it
> next time just in case)

OK, that would work.


>
> > Anyway, I thought saving the client list was just for the V3
> > hubs - and  only because they needed to share that
> > information to enable a seamless changeover.
>
> I just feel that having the new hub handle all this means no need
to change
> any existing app's, only the hub needs replacing
>
> No, it's not perfect I know that
>
> Anyway, I'll go with whatever is decided, but none of my existing
app's will
> be changed (there's too many of them and I just don't have the
time) - so
> users of them will have to live with this if they continue to use
them
>

Well that's your choice of course, and a good reason for any changes
to be backwards compatible.

>From an xPL Diagnostic tool point of view, though it's not ideal,
since the tool will be unable get information from the applications
on demand, and problem resolution becomes that much more of a chore.

Mal






xPL Main Index | xPL Thread Index | xPL Home | Archives Home

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.