ISSUE: getHubID/getSelfID

[Mark Taylor]

On Wed, 30 Apr 2008, Thomas Boch wrote:

>> Currently there is no easy way for a client to find its own ID.
>> Should there be a getSelfID() method?  Or should this value be
>> returned by the register method (note the Standard Profile register()
>> method currently returns a private key specific to the application,
>> but this is not in general the same as the public id).
>
> I think we can have both. The register method could return a map with
> keys 'private-key' and 'public-id' along with the corresponding values.

On reflection, I think that's a good idea.  If register() returns a map,
it also makes it easier to return additional information to the registering
client if we find in the future that there's something else we haven't
thought of (by just defining a new map key).  In fact it would also possible
to use this to return the hub ID, instead of having a separate getHubId()
method (it's a separate question whether that's an improvement or not).

So we could have in the abstract API (sec 3.10):

     map reg-info = register()

        where reg-info must contain the entries:
           clientid: a string giving the newly registered client's client ID
           hubid:    a string giving the hub's client ID

this being modified in the Standard Profile (sec 4.2):

     map reg-info = register(string samp-secret)

        where reg-info must contain, as well as clientid and hubid, the
        additional entry:
           privatekey: a string giving the client's key for hub communication

similar comments apply to this as about the "ISSUE: Naming of error object
encoding" point - i.e. it might be better to call the keys "samp.clientid"
etc.

-- 
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/