Prev: FAQ Topic - Javascript Libraries (2010-05-22)
Next: Acheter ACEON pilule enligne
From: David Mark on 25 May 2010 08:33
Thomas 'PointedEars' Lahn wrote:
> David Mark wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> [optional gzip-compressed HTTP response body]
>>> You have to do content negotation alright, but you surely don't need "two
>>> copies of each static file".
>> You would with my host. I can't just install any old CGI program.
>
> You don't need to install anything with cgi_buffer. You put the scripts
> (written in Perl, Python or PHP) where you need them, and include them.
> Yes, cgi_buffer is old, but it works well (I use the PHP version because I
> want cache control for those, too).

But, none of those languages are supported with my account. It's just
ASP. AFAIK, I am limited to JScript or VBScript.

I've always figured I'd switch to a server with GZIP enabled when I got
to the point where it mattered. My current host may even provide such
an account. I'll look into it when the time comes.

>
>> Trust me, I've looked into it. All I could do is write an ASP to do the
>> negotiation and serve the appropriate file. I've considered and
>> dismissed the idea (for reasons that should be obvious).
>
> The reasons are not obvious. If you can have the My Library builder in ASP,
> there is no good reason why you could not have a cgi_buffer equivalent in
> ASP.

Of course I could. Then I would need to use ASP wrappers for all of my
static files. Why should I bother when I can just switch servers and
use the same old static files? I would much prefer a transparent solution.

Certainly it is faster (and much simpler) to serve static files as well.
I just drop updates in with FTP and the server takes care of the rest
(which will include the negotiation and GZIP bit once I move to a new
host or account).

Furthermore, most of my HTML files are so tiny that it doesn't matter.
The only people who could conceivably complain are dial-up users and
their modems take care of the compression anyway. So I don't see any
huge upside to complicating things.
From: nick on 25 May 2010 17:04
On May 23, 3:45 pm, Johannes Baagoe <baa...(a)baagoe.com> wrote:

> It seems to me that two straightforward functions is all that
> is needed. A bit like those :

http://stackoverflow.com/questions/294297/javascript-implementation-of-gzip#answer-294421

This example really helped me a lot... I understand the original code
much better now.

> (Except that they don't work - they fail my "French taxpayers" test
> string much worse than your implementation.)

Here's a version combining ideas from current press.js and the code
you linked. This should work with any characters supported by js.

http://jsbin.com/egemu3/edit

It's less efficient that the current press.js. I think it's because
the new version uses a simple 7-bit numeric encoding, and the old
version uses a different method which I don't quite understand yet:

ValSizeInBits : function() {
// How many bits are we currently using to represent values?
var log2 = Math.log(this.nextcode + 1)/Math.LN2;
return Math.ceil(log2);
}

http://code.google.com/p/pressjs/source/browse/trunk/src/compdict.js#32

I'm trying to figure out what the old version was up to with the byte
encoding and work it into the new version.
First  |  Prev  | 
Pages: 1 2 3 4 5 6 7 8 9
Prev: FAQ Topic - Javascript Libraries (2010-05-22)
Next: Acheter ACEON pilule enligne