[Cdk-devel] JmolModelAdapter + CDK IO

[Miguel H. <mt...@mt...>]

Egon wrote:
> I've had a look at dynamically switching the model adapter... but
> could not  really find a way to do this.... suggestions?

I did a little work on the CDKJmolModelAdapter today ... as part of the
work for Christoph.

And I have been thinking a lot about the problem and have general ideas.

Here are my general thoughts ... and the line of investigation I would
like to pursue:

 * Jmol needs to support the ability to load different model adapters.

 * I have been successfully using some 'dynamic class loading' in part
of the Jmol rendering code and I am happy with it. Classes which
implement an interface (or subclass an abstract class) can be
dynamically loaded by the string name of the class. We need to apply
this type of technique to the JmolModelAdapter.

 * I think that the problem of reading data from CDK data structures
(after
calculations have been performed) should be separated from reading
directly from files.

 * In general I do not think that we should generate the CDK data
structures only in order to read a file into Jmol.

 * I would like for Jmol + CDK (+ JChemPaint?) to be able to share a
low-level/lightweight/fast IO library.

 * So, I would like to consider splitting out the CDK file reading into
a
separate package. This package would get built on its own and would
define and implement an API like the JmolModelAdapter.

 * A well-defined ModelAdapter API should work for both reading and
writing of files.

 * This is the next thing I want to explore. It is important to me to
get broader IO support integrated into Jmol. And it will be a piece of
CDK that I can work on without getting overwhelmed.

 * I may still be naive and there may be structures / properties /
characteristics / attributes that will not fit well into this model.
But I want to try it.


I have some questions for you:

Q: What is the file IO model for JChemPaint?

Q: How many file types are currently supported by CDK?

Q: What is the most complex file type supported by CDK?

Q: What kinds of characteristics/properties/attributes to atoms have
that I am not aware of and have not seen yet?


Q: Overall, what do you think about this line of thought?



OK, so there are a couple of possible lines of development we could
follow. They are not really mutually exclusive, we may end up doing a
mixture of all of them.

1. The Jmol PDB reader is much more functional and faster than the PDB
reader in CDK. We could try to move the PDB reader to CDK ... but do so
in the following way: We actually make CDK read the JmolModelAdapter ...
and the Jmol PDB reader comes along with it for free. This helps us
prove that CDK can read files through the JmolModelAdapter. And, to keep
us focused, we have a specific measurable goal of replacing the CDK PDB
reader.

One big problem with this approach is that *I* don't have a good way to
test it. Since I don't actually use CDK I don't really know how to set
up an environment to read and test and make sure that everything is
working properly. It occurred to me that I could build a little system
where I read everything into CDK and then transfer it to Jmol, but that
seems quite complicated.

Q: Comments? Suggestions?


2. We could start by pulling out all of the CDK IO code and packaging it
up into a standalone library.

We can leave it within the CDK cvs, but make it its own project.

We are eventually going to end up doing this anyway. Then we could try to
make both CDK and Jmol use this common IO library ... and share the same
ModelAdapter API.

In some ways, this sounds more difficult. But from my perspective it has
the major advantage that I can do the Jmol side ... where I am more
comfortable. You can work on the CDK side. We can both work on the IO
library.


3. You direct me to the most complicated/comprehensive/unique file type on
the CDK side (CML?) I port it to the JmolModelAdapter API. Along the way I
learn about characteristics/structures that the JmolModelAdapter does not
support.


After having written this I am thinking that a blend of #2 and #3 might be
a good approach.


I need to go ... let me know what you think.


Miguel