registration and declarations to the hub in a single atomic operation

[Luigi Paioro]

Hi Yohann,

if I understand your point, what you are proposing is to add (in a next 
version of SAMP) a registration operation like:

map reg-info = register(map metadata, map subscriptions) [*]

right?

Cheers,

   Luigi


[*] this operation could be an overriding of the present map register() 
operation or just another operation with a different name.


Yohann Granet ha scritto:
> yep!
> 
> Thomas Boch a écrit :
>> Hi Yohann,
>>
>> I'll just reply from a standard point of view, and will let Mark reply 
>> on the JSAMP implementation details.
> of course :)
>>> I just wanted to expose my point of view concerning the way by which 
>>> JSAMP clients register them and declare their metadatas and 
>>> subscriptions.
>>
>> I think JSAMP API just follows the SAMP protocol API, where 
>> registration, declaration of callback information, declaration of 
>> metadata, and declaration of supported messages are different steps.
>> In PLASTIC, we had a single call, and we splitted it in 4 steps on 
>> purpose. A client might want to update its metadata and/or the 
>> messages it supports according to the current list of subscribed 
>> clients, or to adapt to some messages he had to process, etc.
> I understand the flexibility given by these distinct methods...
> but I think it would be nice to have the possibility to avoid 
> transitional (and, I think, almost always not wanted) states in the hub 
> where clients informations are incomplete!
> 
>>> 1) a more simple way to register a client: 1 method instead of 4 for 
>>> now.
>>>
>>> something like
>>>    hubConnection = clientProfile.registerCallableClient(this, 
>>> metadatas, subscriptions);
>>>
>>> instead of
>>>    hubConnection = clientProfile.register();
>>>    hubConnection.setCallable(this);
>>>    hubConnection.declareMetadata(metadata);                   
>>> hubConnection.declareSubscriptions(subscriptions);
>>>
>>> (and if a client needs to change its metadatas or subscriptions?... 2 
>>> solutions:
>>>    - unregister, then register again (a client with new informations 
>>> can be considered as a new client)
>>
>> I think I don't like this idea very much. First, it does not match 
>> with the agreed SAMP abstract API.
> damned!... and SAMP is frozen? :)
> is it inconceivable to create a new registration method allowing a 
> simplification in the registration-declarations operations and giving 
> more stability and security?
> for the moment the registration way is made to allow an application to 
> declare its metadatas and MTypes after the registration step... OK, 
> that's fine. Why not?... (even if I don't see a reason to do that)
> but with a "all in one" registration method this possibility is 
> conserved. All man has to do is to give a null or empty value as 
> metadatas and/or MTypes parameters. And if the need occurs to declare 
> them later (or modify them) the
> actual "declareMetadatas" and "declareMType" methods can be used (and 
> "setCallable" also...).
> like that everybody is happy.
> simplicity, security, flexibility.
> 
>> Secondly, imagine that client A is interacting with client B. If 
>> client B decides for any reason to change its metadata, it means it 
>> unregisters and registers again, and client A has no way to know that 
>> the newly registered client is actually the former client B he was 
>> interacting with.
> I agree that if applications A and B need a steady communication to do 
> their job, an identity exchange of one these application can be 
> problematic...
> 
>>
>>>    - create new "updateMetadatas(Metadatas metadatas)" and 
>>> "updateSubscriptions(Subcriptions subscriptions)" methods.
>>> ) 
>>
>> Unless I miss something, that's exactly the role of the existing 
>> declareMetadata and declareSubscriptions method !
> (yes...
> you're right!  :D
> I just talked about new methods for the case the declarations steps were 
> include in the registration operation...
> but even there it's stupid to change the name of these methods...
> sorry)
>>
>> Cheers,
>>
>> Thomas
>>
> 
> thank you Thomas for your answer
> Cheers also :)
> 
>    Yohann

-- 

Luigi Paioro

INAF - IASF Milano
Via Bassini 15, I-20133 Milano, Italy

Phone  (+39) 02 23 699 470
Fax    (+39) 02 26 660 17
Site   http://www.iasf-milano.inaf.it/luigi/