Hub stopping

[Mark Taylor]

On Tue, 6 May 2008, Alasdair Allan wrote:

> Looking through the current specification it appears that every client is 
> forced to call getHubId() right after it registers because at the moment 
> there isn't any way for it to know that the app.event.stopping message it's 
> recieved from the Hub is from the Hub or not... wouldn't it make sense to 
> have a hub.event.* set of messages that all (callable) clients were required 
> to be able interpret rather than having each client call getHubId() and then 
> be forced to handle all app.event.stopping messages?
>
> This makes more sense than just fixing the hub public id to 0 because...
>
> Under the current system all callable clients have to subscribe to all 
> app.event.stopping messages and scan them to see if the Hub is stopping. But 
> there is a big subset of cases, where I'm a client that is callable, but only 
> really sends (broadcast) notificatons, where I would still be interested in 
> the hub stopping messages (but not the rest of the app.event.stopping 
> messages) so that having a separate hub.event.* class of messages is much 
> more convenient.

Alasdair,

I almost completely agree with this, for the reasons that you cover -
hub.event.stopping (and possibly other hub.event.*) messages should
exist separate from app.event.* ones. 
The only thing I disagree with is:

> have a hub.event.* set of messages that all (callable) clients were required 
> to be able interpret rather than having each client call getHubId() and then

there is no *requirement* for callable clients to interpret such 
an MType - they can ignore it (at their peril) if they want.

Mark 
(catching up with messages following a week's holiday)

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/