Add new comment

But another problem raise: -

But another problem raise:

- imagine someone installed, say, Program1 0.AA.BB with LibRaw 0.11 (shared)
- then he/she wants to try, say, Program2. Progam 2 requires LibRaw 0.13-Beta (shared) because it uses exposure correction feature.

So, user SHOULD rebuild/reinstall Program1 with LibRaw 0.13. But he wanted only to play 5 minutes with Program2, nothing more.....

The shared library are very good idea if
- API/ABI is very stable (but frozen API stops development of new features)
- API is made via non-virtual function calls instead of direct access to parameters structure. This way produces zillions of getters/setters with no idea behind. Also, it is harder to make C++ derived classes, because virtual methods table is fixed too, so no way to add/change function calls.
- there are good .SO/DLL version management, so each program uses own version of LibRaw.so/dll. But this broke the idea of quick 'security/bug fixes'.

You may be *stable* (in terms of API/ABI) but it will slow progress because programmer will need to do tricks (to stabilize APIs and so) instead of doing things.

I hope, after verisions 0.14 or 0.17 LibRaw will be stabilized: we need plugin registration interface, so all extensions will run with stable internals. But not now.

-- Alex Tutubalin @LibRaw LLC