Re: =[xhr]

Thank you for the quick reply. I have been traveling and just noticed it.

I think you misunderstand. If you want to see what I have, take a look at
any of the demos in http://chemapps.stolaf.edu/jmol/jsmol, in particular
http://chemapps.stolaf.edu/jmol/jsmol/jsmol.htm or
http://chemapps.stolaf.edu/jmol/jsmol/test2.htm There are hundreds of
implementations of JSmol out there. We are seeing documented (very partial)
use involving 150,000 unique users per month utilizing JSmol. Maybe a drop
in the bucket, but it's a pretty good chunk of chemistry involving just
about any involvement of molecular models on the web. I can give you some
examples: http://www.ebi.ac.uk/pdbe/pisa/pi_visual.html
http://www.rcsb.org/pdb/explore/explore.do?structureId=1RRP just to give
you an idea.

Jmol utilizes a virtually complete implementation of Java in JavaScript.
Including Class.forName() -- that is, Java reflection. Now, the reason that
is done is that with 150,000 lines of code, you don't want to load the
whole thing at once. Good programming practice in this case requires
modularization, which Jmol does supremely well, with over 150 calls to
Class.forName().

Yes, sure, a lot of it can be done asynchronously. And I do that as much as
possible. But I suggest *there are times* where synchronous transfer is
both appropriate and necessary. The case in point is 50 levels deep in the
stack of function calls when a new "Java" class is needed.

You want me to make the asynchronous call, which could involve any number
of dependent class calls (most of these are just a few Kb -- they do NOT
detract from the user experience -- drop the thread (throw an exception
while saving the entire state), and then resume the state after file
loading is complete? Has anyone got a way to do that with JavaScript? In
Java it is done with thread suspension, but that's not a possibility.

Wouldn't you agree that a few ms delays (typically) the user experience
would be far worse if the program did not work because it could not
function synchronously or would have to be loaded monolithically?
Downloading 5 Mb in one go would be a terrible experience, obviously,
asynchronously or not.

I'm simply reacting to what I am sensing as a dogmatic noninclusive
approach. Are folks really talking about disallowing synchronous transfer
via XMLHttpRequest? No use cases other than mine? Really?

Can you also then give me creation of threads (not just web workers, but
actual full threads for the DOM) and allow me to suspend/resume them? That
seems to me to be the necessary component missing if this spec goes through
removing synchronous file transport.

This is not a minor matter. It is a very big deal for many people. I assure
you, this will break hundreds of sites in the areas of general chemistry,
organic chemistry, biochemistry, computational chemistry, crystallography,
materials science, computational physics, and mathematics -- today, if
browser designers follow the recommendation to "experiment with throwing
<http://dom.spec.whatwg.org/#concept-throw> an "InvalidAccessError
<http://dom.spec.whatwg.org/#invalidaccesserror>" exception"

It will shut down essentially all sites involved in web-based molecular
modeling.

Why so draconian a recommendation?

I'm very seriously concerned about this -- that it would even be suggested,
much less implemented.

Again, I understand your concern. But absolutely seriously, this
recommendation is actually, in my opinion, simply irresponsible. Peoples
*livelihood* could be destroyed. (Not mine, I mean all those working on the
professional sites that depend upon Jmol/JSmol for their proper function.)
Huge huge expenses to figure out a work-around.


Bob Hanson
Principal Developer, Jmol/JSmol






​