CLAM devel

Introduction

Welcome to the first published CLAM Roadmap. The current version of CLAM is="article">

Introduction

Welcome to the first published CLAM Roadmap. The current version of CLAM is 0.6.1 (May 2004) and this document describes the master lines of development aiming towards CLAM-1.0, which is due sometime before the end of 2004. This roadmap gives also a necessary context for understanding the CLAM extreme stories which are much smaller units of progress (typically developed in a few days). The progress of these stories is tracked in the CLAM devel space.

The roadmap to CLAM 1.0

1. Automated Flow
   1. Full-featured Network Editor: CLAM's Rappid Prototyping tool. Until now the Network Editor was only capable of including simple time-domain Processing Objects. The goal is to be able to include all sort of Processing Objects. More precisely, the Network Editor should be capable of reproducing the SMS Analysis/Synthesis Algorithm including intermediate transformations.
2. Use of Automated Flow features in the Manual Mode. Many of the new features introduced in the Automated Flow will make the life of CLAM users easier even if they are using the Manual Flow. We intend to promote their usage.
   1. Use Ports. Instead of declaring intermediate data objects and passing them as arguments of the Do operation, it is much easier to use Ports to connect Processing Objects in between them.
3. CLAM deployment. Now it is difficult to install and use CLAM. We are heading toward a more usable environment.
   1. Remove dependencies with third party libraries when not strictly necessary. Now, especially in GNU/Linux, you need to have all third party libraries installed in your system even though you are never going to use some of them. This issue should be solved in next releases.
   2. Better package structure. Now we have very few namespaces/packages. The idea is to clearly identify more or less independent components and group them into understandable packages such as CLAM::Base, CLAM::ProcessingRepository, CLAM::SMS, etc...
   3. Binaries. The compile time and deployment would greatly benefit from having binary packages of the framework.
4. Enforcing CLAM's framework good practices. We have realized that the interfaces and services offered in many of CLAM's components are over-designed. Some of its features are never used and furthermore, this flexibility promotes misuse and unnecessary complexity
   1. Cleaning up and clarifying of Processing interface. The goal is to remove all unnecessary interface and enforce the strict use of some design principles for all CLAM users developing their own Processing class.
   2. Cleaning up duplicated, old fashioned or unused code around CLAM and CLAM examples.
   3. Extending the test coverage to most of the CLAM code, and enhancing the test infrastructure in order to be easier for the processing writers to do their own testing.
5. Clarifying Processing Data use. Just as in the previous point, we have seen that most Processing Data classes offer a too complex interface.
   1. Making Dynamic only what needs to be Dynamic. Dynamic Types are a good thing and they offer many interesting services (such as automatic XML storage, homogeneous interface...). Nevertheless, the dynamic mechanism for adding and removing attributes at run-time is sometimes more annoying than useful. The goal is to identify when and where DT are strictly necessary and only use them there.
   2. Clarifying the use of the Spectrum class. The Spectrum class is very flexible but also too complex. Also by making some conversions transparent it is hiding from the user the fact that some practices are not efficient and should not be done inside a Do() operation. We may need to offer specialized spectrums which are efficient and explicit while keeping the current interface as a wrapper only to use in particular cases.
   3. To dB or not to dB. The use of linear/dB magnitudes in CLAM is not well solved so we need to devise a mechanism for taking care of this issue. This solution should aim at being both transparent and efficient.
   4. In some Processing Data classes it would be interesting to have inheritance capabilities. This is now limited because of the use of DT. We have a version of DT allowing for inheritance but maybe it is not necessary after deciding when DT are to be used.
6. Descriptors infrastructure. At this moment, CLAM offers a limited infrastructure for computing and using descriptors related to the Processing Data. In many of our internal project we have seen the need for a more exhaustive solution to this problem that will address issues such as its efficient computation, storage, representation, retrieval... See this development document with the current ongoing work.
7. Integrating result of CLAM related projects. CLAM has been used in a number of internal projects that have developed algorithms and applications. We are in the process of integrating their contributions.
8. Improved documentation. Current CLAM documentation have grown very big and difficult to mantain, we are heading towards:
   1. Convert the current manual into a smaller, more modular and conceptual documentation, moving out the interface details to the doxygen documentation.
   2. Make the doxygen documentation a more useful tool. Add modules grouping related classes, and improving the non-automatic (writen) documentation in general.
   3. Promote small tutorials.
   The three kinds of documentation should provide enought links between them, so helping the user to find what she's looking for.
9. Improved SMSTools. SMSTools is CLAM's flagship application. Although it is now more or less functional there is still much place left for improvements. We aim at having a better and more complete documentation including tutorials, a better interface (probably in QT), a better design of the overall application, and the possibility of managing workspaces and projects.