registration and declarations to the hub in a single atomic operation

[Mark Taylor]

On Thu, 19 Feb 2009, Yohann Granet wrote:

> Hi Mark,
> 
> It's kind of you to try to give me help about the problem I had and I thank
> you for that.
> 
> But this problem was minor and, as you showed, different solutions exist...
> If I exposed my case it was just to show that the actual registration and
> declaration way could involve problems.
> The SAMP frameworks are intended to be easy to use (of course) and if traps
> can be avoid they should be (I think).
> 
> Besides, for me, it is conceptually and technically wrong to separate the
> registration and declarations operations because:

> Besides, for me, it is conceptually and technically wrong to separate the
> registration and declarations operations because:
> - it is specifically oriented to allow applications to register only or to
> register and declare metadatas and MTypes later, although these cases are
> ultra rare (...and a bit strange: the first case is an application just
> wanting to send messages incognito, the second one... an application which
> doesn't know yet its own informations but still wanting to be registered right
> now(?!??))   
> - it obliges every application to pass by transitional states in
> the hub where it's "profile" is incomplete (transitional states are never
> comfortable!)
> - it obliges developer to use successively 3 or 4 (with the "callability"
> setting step) methods instead of 1 only.
> - it multiplies needlessly the number of messages sent to the hub.
> 
> Having said that I acknowledge that the actual procedure allows a fine and
> easy management of registration, metadatas declaration and subscription
> events.
> that is an argument.
> but new MTypes for hub events could be imagined to signal new different kinds
> of registration (of course, not as much easy but conceptually more right)
> 
> that's just my developer's point of view

Yohann,

I'm sorry not to have replied earlier, I got sidetracked...

In fact, thinking some more about what you say, I have got some 
sympathy with your views about transitional states (though I don't 
think the points about increasing the number of client calls or
messages to the hub are serious issues with the existing arrangement).

In designing the interface we deliberately separated the registration, 
metadata declaration and subscription declaration for a few reasons.  
The two main ones that I recall were:

 (a) The registration call can take different forms, depending on profile,
     and by separating that from the other things, the amount of the
     interface which was profile-dependent could be minimised.

 (b) A clients might well want to change its subscriptions while
     remaining registered (the user might ask it to start/stop 
     listening out for a certain kind of message), so the subscriptions 
     declaration should be separate from the registration.  By symmetry, 
     it seemed tidiest to do the same for metadata declaration.

Item (a) still makes sense.  But I admit that item (b) is not itself
a strong reason for separating metadata declaration from registration,
and I agree with you that I can't think of a persuasive case for a
client needing to change its metadata (though perhaps there is one?).
Moreover you're right that it does complicate matters a bit for 
implementations that a client may or may not have metadata at any 
given time - it makes it harder to refer to it by name in logging 
messages for instance.

So if we were starting from scratch, I might agree there's some merit
in combining registration and metadata declaration, though not 
subscriptions declaration, in one administrative MType for the benefit 
of receiving clients (samp.hub.event.register-with-metadata).
This would presumably, though not necessarily, go with a similarly
modified hub registration call (map reg-info = register(map metadata)).
However, at the point you raised the issue, the document RFC period had
finished, and so it was too late to make that kind of change to this
version of the standard.  I think we could bear this point in mind 
and maybe revisit it if and when we come to update the standard in 
a future version, though even then we'd have to consider backward 
compatibility issues.

Thanks for your contributions.

Mark

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