Re: =[xhr]

I work on applications of over 200,000K LOC and we load everything in

> one go, are you bundling and gzipping your source? Minifying?
> 150,000 LOC doesn't seem to require this complexity.
>
>
We must be talking about two different things. Yes, the bulk of the code is
minified. It is still several MB. That's not the point.



> > Jmol utilizes a virtually complete implementation of Java in JavaScript.
>
> I hope you aren't trying to force idoms from one language and
> environment into a totally different one and then complaining that
> there is an impedance mismatch.
>

I'm not "forcing" anything -- You can see what I am doing, I think. All my
programming is done in Java; this is then ported to JavaScript using
Java2Script in Eclipse. This works spectacularly well. I have no worry
about forcing anything. The structure in the end is identical to the Java
structure, of course. That is the beauty of it. So we have rather deep
stacks of function calls.

My primary concern right now is that the proposed specification explicitly
*suggests* that browser developers "experiment" *now *with breaking
virtually all chemistry/physics/materials science/biochemistry pages
utilizing molecular visualization. Right now I just desire a simple change
in that warning message. I get  the message. I don't need to have it shoved
down my throat by having some browser actually do that and kill all these
pages. This is totally out of place in a specification, and I can only
think that it was added without due thought to the very serious
implications.

Bob Hanson



> B.
>
> On Sun, Aug 31, 2014 at 11:12 AM, Robert Hanson <hansonr@stolaf.edu>
> wrote:
> > 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
> an
> > "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
> >
> >
> >
> >
> >
> >
>



-- 
Robert M. Hanson
Larson-Anderson Professor of Chemistry
Chair, Department of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900