Re: [Jmol-users] local testing ready iteration 1,203,304,440

[Jaime P. <jai...@we...>]

Rolf,

Maybe the way I work on Proteopedia might help you.

I have a CGI script that sends the content of the structure files to Jmol/JSmol: getlateststructure

The script gets as a parameter the name of the file to return or the PDB id for that file, and looks for the ending “.gz” on that parameter. This “.gz” ending gets removed from the actual name of the requested data and kept as a flag of the type of data required. No additional CGI parameter is required.

If the “.gz” flag is present then the script will do whatever its necessary to get the data and send it gzipped. Otherwise it will send it uncompressed. This is, depending on the request, the script will uncompress compressed files before sending, or will compress plain data, to keep the receiving applet happy.

Jaim

On Dec 2, 2013, at 2:20 PM, Rolf Huehne <rh...@fl...> wrote:

> On 12/01/2013 09:42 PM, Robert Hanson wrote:
>> On Thu, Nov 28, 2013 at 12:12 PM, Rolf Huehne <rh...@fl...>wrote:
>>> If someone could tell me a way to convince browsers to uncompress
>>> gzip-compressed CGI output before feeding it into JSmol I would be happy
>>> to implement it.
>>> 
>> I think your server is not set up to deliver gzipped files automatically.
>> Perhaps?
>> 
> The problem whith this is here that the file content is served by a CGI 
> script instead of a static file. As far as I could find out the Apache 
> web server configuration options don't seem to be usable in this case.
> And switching to direct file serving is not really an option for me.
> 
> I am working on a way to mimic it by the CGI script but it doesn't work yet.
> 
> There might be an additional more general way (not only for standard 
> compressed binary files) to avoid sending the data three times involving 
> a PHP script. A CGI script could serve the binary data directly encoded 
> as base64 without the need for an additional PHP script and two 
> additional data transfers.
> 
> I think there would be needed two configurable options for this:
> 
> 1) A special CGI binary mode indicator in the file URL (like the '.bin' 
> file extension). In my case this could be for example "cgi-bin/idb_send.pl".
> 
> 2) A special parameter attached to the CGI URL, e.g. "&ENCODING=base64" 
> by JSmol.
> 
> Option 2) would prevent that base64 encoding would have to be done also 
> with Java although it wouldn't be necessary there. Since the actual 
> 'Jena3D Viewer' CGI script (3d_mapping.pl) doesn't know in advance if 
> Java or HTML5 will be chosen by the client it would be better to add the 
> 'ENCODING' parameter only if necessary on the client side by JSmol.
> 
> Regards,
> Rolf
> 
> -- 
> 
> Rolf Huehne
> Postdoc
> 
> Leibniz Institute for Age Research - Fritz Lipmann Institute (FLI)
> Beutenbergstrasse 11
> 07745 Jena, Germany
> 
> Phone:   +49 3641 65 6205
> Fax:     +49 3641 65 6210
> E-Mail:  rh...@fl...
> Website: http://www.fli-leibniz.de
> 
>           Scientific Director: Prof. Dr. K. Lenhard Rudolph
>        Head of Administration: Dr. Daniele Barthel
> Chairman of Board of Trustees: Dennys Klein
> 
> VAT No: DE 153 925 464
> Register of Associations: No. 230296, Amtsgericht Jena
> Tax Number: 162/141/08228
> 
> 
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT 
> organizations don't have a clear picture of how application performance 
> affects their revenue. With AppDynamics, you get 100% visibility into your 
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
> _______________________________________________
> Jmol-users mailing list
> Jmo...@li...
> https://lists.sourceforge.net/lists/listinfo/jmol-users