ISSUE: getHubID/getSelfID

Mike Fitzpatrick fitz at noao.edu
Wed Apr 30 11:37:08 PDT 2008


On Wed, Apr 30, 2008 at 5:14 AM, Mark Taylor <m.b.taylor at bristol.ac.uk>
wrote:

> I don't like the idea of dictating an ID for the hub. It is much cleaner
> > to have a getHubID method, and this should not put any unbearable
> > additional burden on hub developers.
> >
> I agree with that.
>


There's a difference between unbearable and unnecessary, and note this
affects the
clients as well.

If the hub has an ID like any other app, then the Hub implementor needs to
intercept
messages with its ID a process/reply-to the message rather than deliver to a
client. If
the hub generates a random ID string like other apps, there is the burden
of getting
its own ID and using it to filter every message; if the hub creates a fixed
ID string it is
no better than using an id of 0.

For the client wanting to know that e.g. the app.shutdown Notify is  coming
from the
Hub and not Topcat (where the action it takes may be different), they are
required
to query the hub for its ID and similarly filter based on the ID if the hub
messages  have
any special meaning.

Neither of these is unbearable, but having client-id=0 is a simple way to be
clear that
a message is coming-from/going-to the hub without the extra overhead and we
can
eliminate the getHubID() method  (I think it PLASTIC this was used to ping a
hub to see
if it was alive, but in the draft we now have an isAlive()
implementation-specific method
for that).

The broader question  was whether there was any example of why a client
would need
to send a message to the Hub that wasn't covered by existing methods like
getMtypes():
One such example would be an app.whoAmI Mtype sent to the hub that would be
sent
to return the public ID (in fact this should work for a message to any app
supporting that
mtype since the receiver see the public ID and can reply with that).  Since
this is more
of an administrative message it should be one the Hub supports rather than
relying on
clients, but we could use the message rather than a method to do the same
thing.


-Mike

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ivoa.cacr.caltech.edu/pipermail/apps-samp/attachments/20080430/ca5cb252/attachment-0001.html>


More information about the apps-samp mailing list