For me, I had a browser form and the applet. Before the FF3 security updates
(and now every browser), I used to just have the html file tag and pass the
file path to jmol applet to display, and finally submit to server using html
form again. Now the new security prevents passing the absolute path of the
local file to jmol, I had to use jmol's load "?" to access it. The problem now
is that html is completely out of the loop, ie, i can't have a second html file
tag just for uploading, and getpropertyasstring(filecontents) is not allowed to
pass the filecontents to html. So this is why I figured, the only way for this
setup to work is to implement jmol->server communication to upload files, then
listens for servers response ajax style, and then submit the rest of the
paramers in the html forms to the server. If this works, I might even move the
entire form into jmol so that all parameters can be passed along with the
uploading file.
Rolf, I did look at Jena3D before to see if someone else has already invented
the wheel, but from what I can tell, Jena3D uses the browser file tag to upload
to the server 1st, and then displays jmol applet loading these files from the
server. So in other words, I thought it was a "browser->server->jmol" pipeline.
But if I didn't read it right, I am curious to hear more about the
"Jmol->browser->server" implementation that you are referring to. Namely, I
wonder if the route of passing the file contents of jmol to browser and then
browser to server is do-able.
-Rob
> Date: Mon, 22 Feb 2010 15:16:00 +0100
> From: [email protected]
> To: [email protected]
> Subject: Re: [Jmol-users] how to recompile jmolapplet
>
> On 02/22/2010 01:26 PM, Robert Hanson wrote:
> > If so, it's probably something we should discuss. True, we can already
> > "post" relatively small items using the GET method. Do we want to extend
> > that to POST?
> >
> > Bob
> >
> The size limit with GET is about 8kb. So you can't do much with it.
>
> We currently use the data pipeline "Jmol->Browser->Server->Browser"
> within Jena3D to enable snapshot pictures with the unsigned applet.
>
> The major problem here is the apparent size limit of the "Jmol->Browser"
> part of the pipeline. Creating high-resolution high-quality pictures is
> rather difficult this way. Because it is limited to JPEG (no PNG) and it
> just stops working if the size limit is reached.
>
> One problem with direct "Jmol->Server" communication that I can see is
> that the server response will also (most probably) go to Jmol and not to
> the browser. But I think this could be solved by triggering a second
> contact "Browser->Server" that picks up the result from the
> "Jmol->Server" contact.
>
> This should also open up a reliable way to send state scripts to a
> server. One problem of generating high-resolution high-quality pictures
> with the applet is the limited memory available for the JavaVM as a
> default. This could be solved by generating the image on the server by
> using a state script. Currently the apparently system-dependent size
> limit interferes with this solution.
> And I can imagine plenty of other uses like sending measurement data to
> the server and getting back a plot. A whole new spectrum of possibilities.
>
> > On Mon, Feb 22, 2010 at 4:03 AM, Rolf Huehne <[email protected]> wrote:
> >
> >> On 02/22/2010 04:39 AM, Robert Hanson wrote:
> >>> please let us know what you are adding. If it is of general interest, I
> >> can
> >>> do it, or perhaps it's already there and you don't know how to access it.
> >>> Certainly the signed applet reads files just fine from URLs.
> >>>
> >> For me it looked as if Rob wanted to post data to a server from within
> >> Jmol. This could be of general interest because it would (presumably)
> >> overcome the size limitation that apparently exists in the communication
> >> between Javascript and Jmol applet (currently needed as a detour to send
> >> data from Jmol to a server; like images, state). And it would also
> >> simplify interaction with a server.
>
> Regards,
> Rolf
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Jmol-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/jmol-users
_________________________________________________________________
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Jmol-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-users
