-
There are “external” and “internal” interfaces. Former are for applications, that need widget for displaying molecules (like Kalzium), latter for plugins.
If we suddenly break “internal” ABI/API, only plugins suffer, but clients remain working
If we break “external”, plugins remain working, but clients need re-compilation
-
libavogadro lack modularity. If it was modular, breaking of ABI/API of one module wouldn’t seem to be so disastrous (“oh shi~, the broke whole libavogadro ABI!”) because no client needs everything
Clients which use libavogadro for visualization need GLWidget, engines and, probably, tools. They probably don’t need extensions at all. They probably don’t need special painters which work only for export (POV-Ray, etc.)
Python module should be moved to separate library (and package), not everybody needs it (both humans and external programs)
PlotWidget stuff should be moved to separate library (and package). It’s quite generic and has nothing chemical inside. IMHO, it should be LGPL’ed if its possible to get more contributors
GLWidget and Atom&Molecule stuff may be divided into two different libraries. Maybe some client will need Atom&Molecule API without rendering
I hope these thing will make “libavogadro” more lightweight and usable by 3rd party developers.
–
Regards,
Konstantin
Hi,
On Mon, Feb 22, 2010 at 12:42 PM, Konstantin Tokarev annulen@yandex.ru wrote:
- There are “external” and “internal” interfaces. Former are for applications, that need widget for displaying molecules (like Kalzium), latter for plugins.
If we suddenly break “internal” ABI/API, only plugins suffer, but clients remain working
If we break “external”, plugins remain working, but clients need re-compilation
Not really. If ABI breaks for any of the “external” interfaces,
plugins might be affected too. For example if we change the Tool or
Extension class, plugins derived from these classes will not work
anymore AFAIK. It is ok to break ABI for real “internal” interfaces
(i.e. the headers with _p (for private) at the end). Does this make
sense?
- libavogadro lack modularity. If it was modular, breaking of ABI/API of one module wouldn’t seem to be so disastrous (“oh shi~, the broke whole libavogadro ABI!”) because no client needs everything
Clients which use libavogadro for visualization need GLWidget, engines and, probably, tools. They probably don’t need extensions at all. They probably don’t need special painters which work only for export (POV-Ray, etc.)
Python module should be moved to separate library (and package), not everybody needs it (both humans and external programs)
PlotWidget stuff should be moved to separate library (and package). It’s quite generic and has nothing chemical inside. IMHO, it should be LGPL’ed if its possible to get more contributors
GLWidget and Atom&Molecule stuff may be divided into two different libraries. Maybe some client will need Atom&Molecule API without rendering
There is no way to know which parts (libraries) an application might
be using. So breaking ABI in one of the libraries is as bad as
breaking ABI in the single avogadro library.
I hope these thing will make “libavogadro” more lightweight and usable by 3rd party developers.
Don’t get me wrong, I appreciate your efforts. However, like Marcus
pointed out, getting API/ABI stability was a major goal for 1.0. I
don’t mind breaking it if it is really needed but if a simple
workaround is possible, this would be the preferred way.
Cheers,
Tim
–
Regards,
Konstantin
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avogadro-devel