registration and declarations to the hub in a single atomic operation

[Yohann Granet]

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