Great ideas Bob,
Chemdoodle is 250kb download when minified, but should be even less when it 
comes server-side-gziped. The 800k relates to the unpacked version + sketcher 
code (not loaded when you display mol files) I guess.

The idea of setting up fallbacks is great. A colleague of mine also used video 
as a replacement for Jmol when Java is not there. And everybody doesn't have 
the ability to run a java application server side to create images. That last 
part (no WebGL, no Java) should be very flexible to offer different options 
(server side generation, pngj file, video, any other image file).

Extra thought : Do you think there would be advantages at refactoring Jmol.js 
code in much the same way as Chemdoodle's? (I can only see one : the namespace 
concern and many drawbacks : the backward compatibility break).

Paul

Le 8 avr. 2012 à 08:22, Robert Hanson a écrit :

> I've spent some time looking through the ChemDoodle code. Very interesting! 
> Wow, that's a lot of code -- is that really 800K+ JavaScript download? Really 
> a lesson in logic to see how that all works. Amazing!
> 
> I agree with Keven that Jmol and ChemDoodle are complementary. Jmol has a lot 
> of coverage, but of course not on the iPad or iPhone. ChemDoodle (3D in 
> particular) has a lot of potential, but of course "potential" is the key word 
> there, until browsers and hardware come up to speed. (I'm not sure exactly 
> what actual platforms/hardware support ChemDoodle -- iPad and most Macs, I 
> think; some PCs?)
> 
> What to do? Here's where we are, I think:
> 
> ChemDoodle 3D -- requires WebGL; works with some server-side help
> Jmol -- requires Java; works in browser; can work with server-side help
> 
> There are four platform types:
> 
>  A -- Java but not WebGL (any laptop/desktop; any pre-2010 computer, 
> probably; any computer using standard MSIE)
>  B -- WebGL but not Java (iPad? Is that all? Not sure here...)
>  C -- WebGL and Java (some (all?) post-2009(?) computers using Firefox, 
> Chrome, Opera, or Safari, but not iPad)
>  D -- no WebGL, no Java  (most mobile devices; iPhone, for example)
> 
> Not sure I have that exactly right. 
> 
> Anyway, here's my thought:
> 
> We could put together a system that produces results on all these platforms 
> today. The results would not be perfect, and there would be a variety of 
> options. But it would never produce a message "Your device does not support 
> Java" or "This computer does not have WebGL." 
> 
> It would look like this. Specifically thinking browsers here. (Sounds like we 
> have eBooks covered one way or another.)
> 
> A (Java/no WebGL) -- Jmol uses applet; ChemDoodle uses Jmol applet as 
> second-best option
> B (WebGL/no Java)  -- ChemDoodle uses WebGL; Jmol uses ChemDoodle as 
> second-best option
> C (WebGL+Java) -- Page author decides -- Jmol or ChemDoodle
> D (no WebGL/no Java) -- Server-based user event-adaptable images only (Jmol 
> or ChemDoodle) or static page-author-created PNGJ images (Jmol)
> 
> Say you have a page that would use Jmol if Java is present. The Jmol.js on 
> that page would ascertain the presence of Java and WebGL and:
>  -- if Java is present, use it.
>  -- if only WebGL is present, load the JavaScript for ChemDoodle and display 
> the model that way.
>  -- if neither is present, either present a PNGJ image or use server-side 
> image creation using JmolData.jar on the server. Interactivity only by 
> link/button/menu/etc.
> 
> Say you have a page that would use ChemDoodle if present. Then 
> ChemDoodleWeb.js would ascertain the presence of Java and WebGL and:
>  -- if WebGL is present, use it.
>  -- if only Java is present, load Jmol.js and display the model using Jmol
>  -- if neither is present, use server-side image creation using ChemDoodle 
> (iChemLabs server only) or Jmol
> 
> That's the basic idea.  Comment? Discussion?
> 
> Bob
> 
> -- 
> Robert M. Hanson
> Professor of Chemistry
> St. Olaf College
> 1520 St. Olaf Ave.
> Northfield, MN 55057
> http://www.stolaf.edu/people/hansonr
> phone: 507-786-3107
> 
> 
> 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
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2_______________________________________________
> Jmol-users mailing list
> Jmol-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-users

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

Reply via email to