-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wednesday 25 February 2004 20:44, Daniel Zaharevitz wrote:
> On Feb 24, 2004, at 6:42 PM, Miguel Howard wrote:
> > DanZ wrote:
> >> it seems that CML and loadInLine
> >> are not yet supported. Is this true and if so what are the issues?
> >
> > CML
> > ===
> > CML is probably a good thing for Egon to work on. We have code to
> > support it in previous versions of Jmol and in the CDK (Chemistry
> > Development Kit).
> >
> > One of the major barriers is the bloating of applet size brought on by
> > adding CML support. A larger applet size is not really much of a
> > problem
> > with the Sun JVM (which does a better job of caching). But it is an
> > issue with the MSFT 1.1 JVM that is built into previous copies of
> > Internet Explorer.
> >
> > Q: Dan, who is your target audience and what kind of equipment are they
> > running on?
> >
> > Q: Do you have users on IE who would not want to (or not be able to)
> > install the Sun JVM to get better applet support?
> >
> > Q: What kind of bandwidth do your users have?
>
> Our web pages get ~1.5 million hits/year from ~40K disitinct IP
> addresses. We get about 500 hits per day on the servlets. Of course our
> main concern is to serve the needs of research scientists, but even
> talking to scientists, there is a wide range of equipment,
> bandwidth, computer knowledge, etc. We recognize that using CML (and
> XML in general) can have resource and performance issues, but I haven't
> seen any other technology that
> will get us where we want to go (See more below)
>
> > loadInline
> > ==========
> > loadInline is a serious issue ... and I do not know how to solve it.
> >
> > Most of the file formats are line oriented.
CML does not have this problem.
> > However, the specification of the applet PARAM tags says that newline
> > characters will be removed (stripped out) by the browser. This means
> > that the applet cannot receive a parameter that contains the newline
> > characters.
> >
> > So, stripts work OK ... but you have to terminate the statements with
> > the ; character.
> >
> > Interestingly, this 'newline stripping' behavior means that CML files
> > would work fine ... because they are not line oriented.
> >
> > Q: Why do you want to put things 'inline' ?
There are two approaches... At the Chemistry&Internet conference in
Washington, USA, in 2000 I gave a presentation about java servlets which
streamlined this process... it had a database backend, and servlet
frontends.... Depending on the browser of the user it could do several
things:
1. use an applet with inline CML, or CML provided by a second servlet
2. for older browsers and browsers without java support, it provided a PNG
or GIF of the structure
3. For text browsers it even just gave a description
So making the structure inline is not that important, but at least reduces the
number of requests by half.
> > Q: What type of data?
>
> The narrow answer has to do with the fact that we have structures for
> slightly
> more than 250,000 compounds. At the moment, the 3D structures are almost
> entirely the output from the program Corina from the 2D structures we
> have.
> But we are working our way through a lot of post-Corina calculations,
> including
> conformation search with geometry optimization, semi-empirical QM
> geometry
> optimization and ab initio geometry optimization. So we want to be able
> to
> not do something simple like "show the 3D structure for compound X" ,
> also
> to handle "show and compare the Corina 3D vs the semi-empirical
> optimized 3D",
Isn't that in favor of having separate streams for the data?
> "show and compare all conformations that are within 20 kcal/mol of the
> estimated global minimum". Keeping all this straight is clearly what
> databases are for and we have developed a database that works well for
> us (at least so far). I certainly don't see any reasonable way that
> all this capability can be captured in a set of something like a
> million files that can be referenced by the applet.
But all this data can still be provided by one stream, right?
I don't think a browser minds of a URL is one out of 1M files, or just one
parametarized URL...
> I also don't see
> any reason to make a servlet write out a temp file that is then
> referenced by the applet.
Agreed. That does not make sense... the HTML for the applet can directly
reference to the stream. Still no need for making it inline, or am I missing
something?
To make a point against making the CML inline is the following. To do so, you
either need to break (X)HTML syntax (most browsers are fine with this), or
escape the <'s and "'s... See Jmol website...
There is not proper way to really make the CML inline at this moment, e.g.
using namespaces that browsers can deal with... :(
> As I hinted above, there is a broader reason why we are very intent on
> using XML. We have a lot more than chemical structure data. Chemical
> structure formats are of course optimized for capturing chemical
> structure and do a poor job of allowing for other types of data. Of
> course XML not only allows different name spaces to coexist well, but
> it allows a pretty reasonable degree of independence of development. So
> even though CML was not developed with any interaction with any of the
> gene expression MLs, it is straightforward to combine them when you
> have data on how a compound affects gene expression. As I mentioned
> above, I just don't know of any other technology that has these
> properties. I'll also say that from where I sit, the single most
> important issue
> over the next years is how to build architectures that allow the
> combination of disparate sets of data, including chemical structure.
> You can't begin to seriously investigate how chemical structure relates
> to effects on gene expression until you have an architecture that
> actually allows you to bring all the data together.
I fully agree. (no suprise ;)
> I certainly
> understand that Jmol can't try to do everything, but that is exactly
> the point.
In 1998 or 1999 (can't remember) I joined the Jmol and JChemPaint projects by
hacking in CML support. And I don't plan to have a Jmol release that does not
have CML support. To backup PDB users from the bioinformatics field, I want
also to release an applet that is much smaller in size and does not have CML
support. But *both* will be available.
> If the only way to handle chemical structures with other
> data is to build a new application that is explicitly aware of both,
> then there is a a significant barrier to working in this way.
I've been busy lately, so I have not been involved in many of the discussions,
but let me make crystal clear: Jmol *does* support CML, both application and
applet (see above), and will keep doing so.
> If, on
> the other hand, you have a flexible, modular tool that can extract the
> chemical data out of whatever larger context you have, then you have a
> much lower barrier to doing useful explorations of combinations of wide
> varieties of data. I realize that flexibility and modularity aren't
> necessarily higher priorities than speed and efficiency for everyone
> and so some or most of Jmol development may proceed in other direction,
> but architecture development is at least our most important priority.
>
> > Finally, you offered that these were tasks that your team may be able
> > to
> > help out on. If you are serious about this then let us know. We would
> > love
> > to have some help from people who were interested and capable of doing
> > serious development. I am sure we can find some tasks that are directly
> > related to your uses of Jmol.
>
> I think I gave you an idea of some of the stuff we are looking at. I
> still need to set up some meetings and get a little bit organized
> before I can start to make some specific suggestions. It shouldn't be
> much more than a week or two more.
Ack.
Egon
- --
[EMAIL PROTECTED]
PhD on Molecular Representation in Chemometrics
Nijmegen University
http://www.cac.sci.kun.nl/people/egonw/
GPG: 1024D/D6336BA6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (SunOS)
iD8DBQFAPaxhd9R8I9Yza6YRAvgWAJ0Sqmp/PBrQ/yP+QPGQxjLCIEsH4wCfZqJI
JPvTyOCclW8BkrnM7sLSqsg=
=8lIw
-----END PGP SIGNATURE-----
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id56&alloc_id438&op=click
_______________________________________________
Jmol-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jmol-developers
