[Cubicweb] CubicWeb I/O

Dimitri Papadopoulos Orfanos dimitri.papadopoulos at cea.fr
Tue May 27 23:50:01 CEST 2014

Hi Aurélien,

Le 27/05/2014 15:54, Aurélien Campéas a écrit :
>  [...]
>>   - chaotic releases without a roadmap
> I believe the roadmap is purely customer-driven.
> If you need specific features, bug fixes, etc. you
> should just peruse the forge.
>  [...]

I'm certain the different releases address real-world use cases,
including ours. However the whole point of the "product" approach is to
merge all the different uses cases and provide a stable and consistent
API to resolve most of the use cases and build client software upon.

Of course the above "product" approach does not prevent from
experimenting or releasing proof-of-concept or beta code that can be
later modified or abandoned. Users just need to be informed of what is
stable and what is still tested and subject to change. From our point of
view, we see successive releases of different and incompatible I/O APIs,
which at some point had all been qualified as "ready for production".
Even a message such as "stick to direct session access and HTTP/HTTPS
for now and avoid mass import APIs" would be OK with us. This wouldn't
necessarily prevent us from using an unstable mass import API if needed
- we just need to know it.

> [...]
>>   - bugs in some of the classes
> Please report them.
> [...]

Unfortunately such bugs are expensive to identify and report. Errors are
usually noticed after importing data. For example the GUI might report
errors when viewing the data. We must then find whether the errors are
caused by bugs in views (unable to handle missing attributes for
example) of bugs in data import. For lack of resources we are unable to
handle such complex issues.

Dimitri Papadopoulos
I2BM, NeuroSpin
91191 Gif-sur-Yvette cedex, France

More information about the Cubicweb mailing list