[IPOL discuss] Access to stat on total number of demo archive

[Miguel Colom]

Quoting Bertrand Kerautret <bertrand.kerautret at univ-lorraine.fr>:
> Initially Miguel idea was to split the demo system but perhaps it  
> could more convenient to integrate in the main service. The split  
> solution allows the possibility to start/stop the api web service  
> without interruption for demo service (however cherrypy looks good  
> to reload page without interruption) or to give priority by server  
> access (but not sure that it is really a problem actually ;) ).

Indeed, I think it'd be better to split the demo system into several  
autonomous parts that talk to each other, rather than a single  
monolithic and huge application.

In the case of the archive, for me it's quite clear that we should  
create a different component for it.
Why should the main application take care of all details about  
managing the archive?

The archive should be an independent entity that abstracts the details  
on how to store, index, and retrieve the data.
The core system must be only a client for the archive, and communicate  
with it with simple operations like "tell me the number of experiments  
stored for demo X", "store these images for demo Y", etc

In fact, we're close to that, and all we'd need is to create a new  
standalone application that communicates with the core system with  
webservices using a common API.

This way we'd isolate the details of the archive from the demo system,  
which also means removing complexity from it. And having specialized  
units.

With this architecture, the system can grow scalably.
For example: we could start storing the archives in the same machine,  
then in a separate server in the same LAN, and finally in WAN  
distributed system. All that without changing the core demo system!

In summary, what I intend to say is that, even if we think the system  
will be enough as it is, at the end we'll see that it asks for more  
and more features and demands more resources (more machines, for  
example). We see that already. Then, let's make it scalable and  
modular from the beginning.

Best,
Miguel