Subject: re: CML is dead

From: "E.L. Willighagen" <[email-masked]>
Date: Wed, 12 Apr 2000 12:24:47 +0200 (MET DST)

> I don't want babel! I want native support by *all* chemistry applications.
> That's right *all* applications!

Ah, that would be nice indeed...

For Java i have developed such a toolbox one and a half year ago. I 
would love to see this ported to C(++) as wel... :)

Oke, on native support: since CML is an XML application there are already
file readers for every programming language... you can even select between
different parsing styles: event based (startElement etc, SAX/SAX2) or
object based (element-trees, DOM)...

My Java CML Filter Library is based on SAX... and about DOM. Peter MR is
working on ChemDom (in Java i think), but this is also quite easily
ported to other language, since at is based on DOM which is already 
available in the other directory...

Egon

Java CML Filter Library: http://www.openscience.org/~egonw/cml/

Note that the site is a bit out of date... version 1.2.2
is out but i wanted to write an article first about the changes...

---

From: "Jesus M. Castagnetto" <[email-masked]>
Date: Wed, 12 Apr 2000 05:10:12 -0700 (PDT)

(Are there 2 separate threads of discussion, or someone transposed
"Is CML" to "CML is"?)

This has been a very illuminating discussion, because several libs I did
not know existed have been discussed (like one that Egon mentions below)

On Wed, 12 Apr 2000, E.L. Willighagen wrote:

> Date: Wed, 12 Apr 2000 12:24:47 +0200 (MET DST)
> From: "E.L. Willighagen" <[email-masked]>
> To: [email-masked]
> Subject: CCL:CML is dead
[...snip...]
> would love to see this ported to C(++) as wel... :)
[...snip...]
> Java CML Filter Library: http://www.openscience.org/~egonw/cml/

Now, it would be relatively simple to either use these libs (or other ones
depending on the programming language you are using), to retrofit old
programs, or simply write a wapper that calls the all program and act as
a layer to translate to/from whatever the old program uses and CML, for
all purposes the user will see only CML as output or input, the rest
can be handled by a generic or especific wrapper application.

And this application does not need to be a C or Java program, it can 
be a web application. It can be a servlet that receives a request to
convert to/from CML to the format of choice, and then does it remotely.
Or it can siply be a C program, or a Python, Perl or PHP script.

The existence of this distributed application servers, which would have
low overhead, would allow the writing of generic shell/C wrappers that
can have the URLs harcoded or can pool a directory. This can be slow
for some applications, but for other ones in which is not feasible to
retrofit the old program, it will be a good solution.

Imagine that instead of every single person needing to install the
equivalent of babel for converting from old-format to CML, your program
could just pool a server that tells it where to send its data to be
converted to/from that old-format. If you are connected to the net this
will be completely transparent to the user, and if a new version of the
conversion system is made, it will also be transparent to the user and
the program.

Cheers.

--
Jesus M. Castagnetto <[email-masked]> - "Ken Zen Ichi-nyo"
Program Project:   http://www.scripps.edu/research/metallo/ 
Metalloprotein DB: http://metallo.scripps.edu/
Pilot Stuff: http://www.geocities.com/ResearchTriangle/Lab/1059/

---

From: David van der Spoel <[email-masked]>
Date: Wed, 12 Apr 2000 13:43:02 +0200 (CEST)

>(Are there 2 separate threads of discussion, or someone transposed
Unintended I assume (but not quite sure...)

>convert to/from CML to the format of choice, and then does it remotely.
NOOOOOOOOOOOOOOOOOOOOOOOOOO!
It should also work when I sit in the garden with my laptop! 

>conversion system is made, it will also be transparent to the user and
See above. The web stuff is the icing on the cake. Native support comes
first. I also need this to be able to visualize my 100000 atom system 
so java is out. Native support in *all* applications.

Groeten, David.
________________________________________________________________________
Dr. David van der Spoel		Biomedical center, Dept. of Biochemistry
s-mail:	Husargatan 3, Box 576,  75123 Uppsala, Sweden
e-mail: [email-masked]	www: http://zorn.bmc.uu.se/~spoel
phone:	46 18 471 4205		fax: 46 18 511 755
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

---

From: "Jesus M. Castagnetto" <[email-masked]>
Date: Wed, 12 Apr 2000 06:02:52 -0700 (PDT)

On Wed, 12 Apr 2000, David van der Spoel wrote:

> Date: Wed, 12 Apr 2000 13:43:02 +0200 (CEST)
> From: David van der Spoel <[email-masked]>
> To: "Jesus M. Castagnetto" <[email-masked]>
> Cc: "E.L. Willighagen" <[email-masked]>, [email-masked]
> Subject: Re: CCL:CML is dead
> 

Then pick your wrapper, written in the poison^H^H^H^H^H^Hlanguage of
your choice :)

This will allow you to retrofit your old applications by using a
Python, Perl, Tcl/Tk, or even C/C++ wrapper that handles the conversion
on the fly and then passes the info to the program, this is doable
for interactive and non-interactive programs.

Also, ever heard of broadband wireless Internet connections? ;-)

> so java is out. Native support in *all* applications.

No java? We routinely use a Java 3D application (and rememeber that the
Java3D specs and SDKs are not fully stable yet), to manipulate proteins 
w/ electrostatic surfaces calculated on the flyi (via JPython calls to MSMS).

I do not know what Java applications you have used/seen, but something akin to
AVS is doable. The construction of such tool is being done here at Scripps,
and as part of several projects, one of which is related to the Metalloprotein
DB, which uses a lightweight and small applet to do interactive searches too.

Java is not as fast as C, but it is modular. A well written application
should just load the classes it needs, and handle the rest dynamically 
and using threads appropriately. Also, it is not that difficult to have the
heavy calculation bits written in a native language, that is the reason
for JNI.

And do not discount scripting languages, like Python, which has a good
scientific/numeric support, and a molecular modelling package based on 
Python and Tcl/Tk.

So, I still think that even old pieces of softaware can be retrofited, just
need the appropriate interfacing/wrapping/translation layer, which could
reside locally or somewhere else.

> Groeten, David.

Regards.