press.js - yet another javascript compressor

A

Andrea Giammarchi

You can't just plop GZIP files on the server.  You have to do content
negotiation and would need two copies of each static file (one
compressed, one not).

again, there is nothing to set up. The browser send the header if
present (Accept-Encoding), the server read if it accepts deflate and/
or gzip, the server serves the raw binary file using binary transfer
with length and all the necessary for a basic HTTP request as is a get
over a *whatever* file ... end of the story, when the UA finishes the
download it will decompress locally using the right algo provided by
the server.

The server in this case has *nothing* to do except send right headers,
something it has to do in any case ... than if you have a single
example that does not allow you to serve a binary file I'd love to see
it 'cause to me there is no such case with all I have tried so far
(but hey it's IT, you never know what people use).

Finally, as Stefan Weiss already pointed out, there is no reason to
compress over and over the same file and for each request, libraries
are up to 1mb and more uncompressed, this means stress and this is why
the project I have talked about is fast in the server almost like a
plain text, and 2 up to 10 times or more faster than whatever handler
you use (if you can) since there is *no* runtime compression plus the
Etag is not generated runtime over a compressed version (again, no
reason to compress runtime, *easy*, *simple*, *faster*, until somebody
demonstrates it is not true with benchmarks, those I have already
provided there ... but of course if somebody skip things ...

Br,
Andrea Giammarchi
 
D

David Mark

Andrea said:
again, there is nothing to set up.

Sounds like magic!
The browser send the header if
present (Accept-Encoding),

Uh, yes...
the server read if it accepts deflate and/
or gzip, the server serves the raw binary file using binary transfer
with length and all the necessary for a basic HTTP request as is a get
over a *whatever* file ... end of the story, when the UA finishes the
download it will decompress locally using the right algo provided by
the server.

And you have to configure the server to do that, which my host does not
allow. End of story (I hope).
The server in this case has *nothing* to do except send right headers,
something it has to do in any case ...

And you have to configure it to do the negotiation and send the
appropriate headers. Additionally, for my host's setup, this would
require using a CGI script for every static file. Again, I choose not
to do that (and in fact, my host's setup would make this quite a mess to
do). Instead, at some point in the future, I will simply move my static
files to a host that supports GZIP negotiation out of the box.
than if you have a single
example that does not allow you to serve a binary file I'd love to see
it 'cause to me there is no such case with all I have tried so far
(but hey it's IT, you never know what people use).

What the hell are you talking about now?
Finally, as Stefan Weiss already pointed out, there is no reason to
compress over and over the same file and for each request,

I never said there was. In fact, I mentioned that you would need two
*static* files (one compressed and one not). A lot of the tools out
there (as mentioned) inefficiently compress the file over and over. And
I couldn't use any of them with my host account anyway.
 
A

Andrea Giammarchi

And you have to configure the server to do that, which my host does not
allow.  End of story (I hope).

I stopped here ... hey ... psssssssssssssssss, the link you have
skipped, provides everything via PHP, easy to reproduce the same
serving logic with whatever other server side programming language, JS
included.

Have Fun skipping things setting up your server when it's not
necessary ;-)

Br,
Andrea Giammarchi
 
A

Andrea Giammarchi

a CGI script for every static file

hey ... pssssssssssss, CGI understands requestes, the link you have
skipped uses *one* file for whatever you want to serve ... but please
keep talking about something you did not get, it's fun tho ;-)

Br,
Andrea Giammarchi
 
D

David Mark

Andrea said:
I stopped here ... hey ... psssssssssssssssss, the link you have
skipped, provides everything via PHP, easy to reproduce the same
serving logic with whatever other server side programming language, JS
included.

I'm sure it is easy. I just don't care to bother with it. Thanks!
Have Fun skipping things setting up your server when it's not
necessary ;-)

Mad as a mongoose.
 
D

David Mark

Nice quote. :)
hey ... pssssssssssss, CGI understands requestes, the link you have
skipped uses *one* file for whatever you want to serve ... but please
keep talking about something you did not get, it's fun tho ;-)

I don't care what your PHP script does as my account does not use PHP.
Thanks anyway!
 
N

nick

I don't care what your PHP script does as my account does not use PHP.
Thanks anyway!

You should sign up for my hosting services. But it won't be cheap!

Sorry, I couldn't resist. But seriously, I've got another dedicated
server going up tomorrow... if you want a spot on it let me know,
we'll work out a good rate.
 
D

David Mark

nick said:
You should sign up for my hosting services. But it won't be cheap!

Hosting is a commodity. If it ain't cheap, nobody is going to buy it.
Sorry, I couldn't resist. But seriously, I've got another dedicated
server going up tomorrow... if you want a spot on it let me know,
we'll work out a good rate.

I am going to wait until my current contract is up. I think that is
this fall. Of course, if things keep going like they are, I may have to
move it sooner. :)
 
T

Thomas 'PointedEars' Lahn

David said:
Thanks, I know about that (and other similar scripts) but my host does
not run Apache. It is an on-the-cheap hosting service that I set up
mainly to post examples to. I'm going to be switching soon now that I
actually have something up there I want to promote.

You don't need Apache to do that (there's cgi_buffer, for example). You
have to do content negotation alright, but you surely don't need "two copies
of each static file". That would be ridiculous. GZIP compression can be
done on the fly, and because it is fast, with almost no performance loss.


PointedEars
 
D

David Mark

Thomas said:
You don't need Apache to do that (there's cgi_buffer, for example).

Also incompatible with my current host account I'm sure. Trust me, I've
looked into this. The best solution is to move to another host that has
properly configured servers. My current host gives me virtually no
control over such things. It's a glorified FTP site, which is all I
needed until recently.
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.
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).
That would be ridiculous. GZIP compression can be
done on the fly, and because it is fast, with almost no performance loss.

Irrelevant in the case of my account.
 
T

Thomas 'PointedEars' Lahn

David said:
Thomas said:
[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).
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.


PointedEars
 
D

David Mark

Thomas said:
David said:
Thomas said:
[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.
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.
 
N

nick

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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top