registration and declarations to the hub in a single atomic operation

[Yohann Granet]

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

thank you again for your help
glad to exchange opinions and ideas with you


Cheers

    Yohann



Mark Taylor a écrit :
> Yohann,
>
> On Thu, 12 Feb 2009, Yohann Granet wrote:
>
>   
>> 2) a concurrency-safe way to declare a client to the hub!!!
>> indeed, in case of several clients registering them and declaring metadatas
>> and subscriptions to the hub problems can occur.
>> see my example:
>> I work on an package manager intended to launch applications and retransmit
>> them previously received messages. So my package manager have to listen and
>> react to hub events (subscriptions, unregister events) in order to maintain
>> its own running clients list, to know if there is already registered client
>> having subscribed for every asked MType.
>> When launching several applications simultaneously, if a thread (in the hub)
>> in charge of registration and declarations for a new client "A" is interrupted
>> by another thread in charge of doing the same for a client "B", then when the
>> subscription event caused by "B" is launched my package manager refreshes its
>> client list and then gets incomplete informations concerning application "A"
>> (empty metadatas and/or subscriptions).
>>     
>
> I don't think I follow what's going on in this scenario.
>
> However, since you mentioned in an earlier mail that you were using JSAMP:
> you can use JSAMP's facilities to keep track of clients and their 
> attributes for you.  If you are working from a GUI context, the easiest 
> way is to use the ListModel returned by GuiHubConnector.getClientListModel().
> The content of this model represents the currently registered
> clients along with their declared subscriptions and metadata, and
> it is updated as registration, unregistration, and subscription/metadata
> notifications are received from the hub.
> You can add a listener to this model which will be notified every time
> its contents change.  Of course if you interrogate the list at any given 
> point you stand a chance of getting data which is out of date in
> the sense that an update notification sent by the hub has not yet
> been processed to update the client list, but used properly it's not 
> what I would call "unsafe".
>
> From a non-Swing context, the Map returned by HubConnector.getClientMap()
> does much the same job, though you can't register listeners on it in 
> the same way.
>
> Mark
>
>