[IPOL discuss] Demo system development

[Miguel Colom]

Dear all,
I'd like to share my thoughts about the development of the demo system.
This message perhaps is only interesting for demo editors and  
demo-system developers, since it's quite technical.

I think this kind of messages are useful in order that everybody is  
informed about the status of the system and can give their opinions  
and criticism.

Right now, we have a working demo system that soon will have hundreds  
of demos working. The best about this is that now we know exactly what  
kinds of demos are the "standard" ones and why and how other kinds of  
demos need to be non-standard and how to manage them.

Since the demo system is working, the first issue is that any  
modification should never break the compatibility of the existing  
demos. Or with other words, it should follow an EVOLUTION MODEL [1].  
With hundreds of demos running, it's the only realistic option.

The only exception of the evolution compatibility is BUG CORRECTIONS  
that imply modifying the existing and running demos. However, even  
when such a bug is detected, it demo system should be modified in a  
way that the existing demos keep working until they're corrected.
To do it, it's really useful to use some automated tools in order to  
track which demos have been already modified and haven't.
Such a tool already exists [2] and is able to detect at which lines  
the demos could fail due to a race condition caused by a known bug in  
the demo system (it'll be solved soon).

To ensure that the demo system is easy to maintain and to add new  
features, it's really important to do REFACTORING before and after  
each modification of the code. If not, it might happen that the  
complexity of adding some operation or capability to the system is  
more complex or difficult that the operation itself. To prevent it,  
continuous refactoring is needed. The production of (automated)  
documentation is part of the refactoring processes.

Finally, about the priorities, they should be the following, in my opinion:
1) Bug correction.
2) Refactoring.
3) Adding new features, if needed.

Of course, before starting any new features, they should be deeply  
discussed. This discussing list is a good and necessary starting point.

To finish, I think that a better parameter handling would be  
interesting for the demo system (after correcting known bugs,  
refactoring the code and without breaking existing demos).
In short: declaring the input/output parameters of each demo and also  
their types and default values.
Most of the work that the demo of a user does has to do with reading,  
passing, and storing parameters. If this is automated, the demos can  
be much simpler and opens the door to the integrated demo automation  
(not for the "non-estandard" demos).

With this tips, I think that the demo system will be easy to maintain.
What do you think? Any new idea?

Best,
Miguel

[1] http://en.wikipedia.org/wiki/Software_evolution
[2] https://tools.ipol.im/demo_verifier/
[3] https://en.wikipedia.org/wiki/Code_refactoring