Re: [Jmol-developers] CDK IO integration issues

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

>> My goal is to extend the JmolModelAdapter API so that the CDK data
>> structures could optionally be released once the model is loaded into
>> memory. This would make it easier for a simple viewing application to
>> take advantage of the CDK IO facilities, then release that memory for
>> other uses.
>>
>
> please forgive me if my understanding of this issue is somewhat naive.
> when Jmol opens a structure file, it is loading data from the file into
> its own memory space (and format).  once this is done, Jmol does not go
> back to access the file again.  correct?

Well, that is mostly/kinda correct.

There are a couple of layers involved.

In fact, Jmol itself never reads from a file. It assumes that there is
some library out there that can provide it with information about the
molecular structure. It uses the JmolModelAdapter API to iterate over the
atoms/bonds, etc.

At the present time, Jmol continues to hold on to those data structures
after they are read. Why? Because Jmol sends 'notification' events to the
underlying library. So if the users deletes an atom then the underlying
package is aware of it.

Since noone/nothing is currently using this functionality, we could
disable it.

But the current API holds on to all the data structures in the underlying
model library.

> if that is the case, how about including a few of the most common
> formats in the core Jmol, then building support for different file
> formats as plug-ins to the app, or separate libraries for the applet?  I
> realize this would force developers to work a little harder; however, I
> think user-end is more important.  I think that is what you are
> suggesating above...
Yes, I think that is the basic idea.

> for example, I use the pdb format almost exclusively.  I hardly ever
> need to support mmol.  if I create a Web page that requires mmol
> support, I can add the extra lib.  if a third Web page requires ent
> support, I can add the ent lib.  etc.  this lets me, the developer,
> worry about support versus user issues.  if all of my users are on a
> university pipe, maybe I include support for all file formats; if there
> are a lot of vocal modem users, maybe not ;-)
>
>
> does this make any sense realistically?
Yes.

What I would rather try to do is provide two or three .jar files ...
JmolApplet.jar, JmolApplet2.jar ... then encourage all web developers to
include them in all their scripts. That way, adding support for additional
file types or functionality would be easy.


Miguel