Forwarded to the list for reference.
-------- Original Message -------- Subject: PDB lib Date: Tue, 13 Nov 2007 16:06:24 -0800 From: Daniel Russel drussel@gmail.com Reply-To: drussel@salilab.org To: Ben Webb ben@salilab.org References: 3682E173-8139-44FE-8BB0-C2739807D71E@salilab.org 473A0947.9030501@salilab.org 473A09AD.2000603@gmail.com 473A31BC.1060000@salilab.org
> > At any rate, this PDB reader stuff needs to be discussed on imp-dev > before we proceed. For example, what's wrong with the BALL stuff you > were playing with before? BALL is dead. No activity on email list. No response to bugs. No move to actually document their newest version even though it was released a year ago. I don't think we want to tie ourselves to it. Sure we can take it to IMP dev. No one else seems to care much :-)
I have looked around and asked around and couldn't find any decent PDB readers (in C or C++) which are not buried in some huge project. > Why can't we link against this PDB library, rather than > cut-and-pasting thousands of lines of code? The nice thing about it is that it is small and simple and mine so we can just ship it along with IMP and not worry about dependencies, name collisions etc. I don't want people to have to get another library from somewhere else, hence my desire to put a copy into imp svn. Soon enough the lib will make it to fedora extras (whenever the next CGAL release is) so we could potentially just use that. > Should the kernel include a PDB reader anyway? It doesn't matter if it is in the kernel or a separate lib that is brought along, especially since we are using dynamic linking (so the library can be pulled in my libimp). Everyone seems to want a PDB reader, including me so we need one somewhere. > My concerns are 1. it'll be a maintenance nightmare to fork this PDB > library, Not at all. It doesn't actually need forking other than changing #include <CGAL/PDB to #include <IMP/PDB to avoid stomping on things. I really with there were some way to parameterize such things.
It was written to be self-contained, I just got sloppy with the last few changes so I had to fix those this morning).
> 2. it's LGPL so we can't include it in IMP without being forced to > adopt LGPL (only link against it) Why would we want to do more than link against it? Anyway, changing the license is easy. It was initially free, I just changed the license recently because much of the rest of CGAL is LGPL. > and 3. from a brief reading, it looks like a not-very-good PDB library > anyway (hard-coded atom names - what's with that?) Well, it is either that or use strings which pushes the checks to runtime rather than compile time. Adding to an enum and recompiling is trivial (and adding a constant externally works just as well for must purposes). Checking everywhere than an object falls in a small set of allowed strings is hard (especially if you can't specify that set of strings anywhere). BALL has hardcoded atoms for that matter (just a lot more of them :-)
Anyway, I am a fan of it (as I should be :-) And since our backups are rather less than I thought, the ball code got lost with the constant rechecking out of IMP.