Quoting Bertrand Kerautret <[email protected]>:
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
--
IPOL - Image Processing On Line - http://ipol.im/
contact [email protected] - http://www.ipol.im/meta/contact/
news+feeds twitter @IPOL_journal - http://www.ipol.im/meta/feeds/
announces [email protected] - http://tools.ipol.im/mm/announce/
discussions [email protected] - http://tools.ipol.im/mm/discuss/
