Re: [Plastic-devs] Some ideas

[Alasdair A. <aa...@as...>]

Pierre Fernique wrote:
> Just one point about the Plastic Hub. I wonder if it is not too  
> difficult for a user to understand : if and why he has to launch a  
> Hub ? which one ? if and why he has to register each collaborative  
> applications ? If and how he can stop the current plastic Hub ?

In the past this hasn't been a problem because the hub was the ACR,  
now that this isn't necessarily the case perhaps we have to think  
about it a bit... However I think this is a problem for application  
developers rather than users.

> I) One solution could be :
> --------------------------
> A) When a Plastic compatible application starts:
>    1) If it has an inside plastic hub capability, it launchs it,  
> but only if there is not another Hub already runnning

Or alternatively starts up the generic plastic hub, the hub doesn't  
have to be internal to be started from an application. You only have  
to look at TOPCAT to see examples of how this works in practice.

>    2) Systematically it registers itself

Some applications automatically register themselves (or attempt to),  
some don't, I think that's a choice for the developer.

> B) When this application stops:
>    if it is the last registered application, it tries to stop the  
> hub if it can.

Again seems like a choice for the developer, but yes, this might be  
okay, but only if it was the application that started the hub in the  
first place. After all if it was already running when it started up,  
then the application should leave things as it found them.

> The B) point means that it could be interesting to have a PLASTIC  
> message asking to the PLASTIC hub to stop itself.

Can't we do that already, if not it seems like a reasonable  
capability (message) to add. Although I think there Plastic hub  
should be able to say "no", it should be a request, not a demand.

> Or we can imagine that the PLASTIC HUB should stop itself when the  
> last client unregisters.

No, no and thrice times no. At least not by default. That's an  
absolutely hideous idea. Think of the hub as a backend daemon rather  
than a user level application. Would you stop the crond daemon if  
there wasn't anything currently in a user's crontab file, nope...

> We can also imagine that a plastic hub implementation should remove  
> a registered client if it can not contact it (crash...).

I think it already does this...

> II) Another solution could be:
> ------------------------------
> A) When a Plastic compatible application starts, it does a pre- 
> registration. I mean, it writes somewhere (.plastic dir) that it is  
> running and what is its plastic address (?)

Maybe

> B) When a Plastic Hub starts, it will register automatically all  
> "pre-registered" applications.

Puts a big burden of effort onto the application developer though?  
You now have to be able to cope with lighting up a whole bunch of  
functionality that you'd shut down on start-up because there wasn't a  
hub, for new applications okay. Reverse engineering this into  
existing applications might be problematic depending on the  
architectures involved.

> C) Whend a Plastic compatible application wants to publish data
>    1) If there is no running plastic hub, it tries to launch one if  
> it can
>    2) it publishs its data

To where? If there wasn't a plastic hub running, then there wasn't  
another plastic aware application running on the same machine (under  
your scheme) since they would have already started a hub...?

> The second proposition is certainly the better (the hub is running  
> only if it is required).

I think you view the hub in a very different way that I do, the hub  
is a service not something you start and stop with the starting and  
stopping of a single application.

> But it could imply a complex plastic address negociation between a  
> "pre-registered" application and a new running hub.

The word "complex" in the above sentence worries me a lot. We  
currently have a very light weight messaging system and a fairly flat  
architecture, lets not pile arbitrary complexity on top.

Al.