registration and declarations to the hub in a single atomic operation

[Yohann Granet]

Hello Mark

happy to have some news!

Mark Taylor a e'crit :
> 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.
>   
I didn't know that registration calls were depending on profile...
In these conditions I understand that splitting registration, 
declaration and subscription simplifies the job in the SAMP internal 
processes.
however it's a bit sad that, in order to avoid complex operations inside 
the framework, the solution chosen obliges the SAMP framework users to 
deal with a compulsory split operation of registration and its (little) 
inconveniences...
(yet I don't know the benefit(s) (certainly important) of the actual 
registration way in the SAMP framework internal job!!)
>  (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.
>   
(((with a registration in a single operation the possibility for an 
application to change its metadatas and subscription would be conserved 
by using the actual declaration and subscription methods)))
> 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.
>
>   
OK with your conclusions :)
> 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.
>   

OK OK
(I knew that I was running a bite late :D )
> Thanks for your contributions.
>
> Mark
>
>   
Thank you for paying attention to my remarks
see you soon

Cheers


Yohann