Free software distribution ideas

Created a PHP script for gzipping static files to be sent to browsers using Apache on *nix. Now, I don't see this as a major project that'd be worth the time putting on sourceforge or something. But, any ideas on how to distribute it?

Dude, you've just reinvented the wheel. Go look up mod_gzip sometime.

I know, I know. But mod_gzip generates the gzipped version every time(does it not?) and not every host uses mod_gzip. This script is for a per-directory one-time generation of files after which you can use directives in the httpd.conf or let it generate .htaccess files for you to handle browsers that send the gzip accept-encoding header. Sounds less load-intensive to me.

>>3
I know, I know. But mod_gzip generates the gzipped version every time(does it not?)...

Someone has clearly done their research before implementing a pointless project.

Well done.

I'd think mod_gzip would be mature enough to do caching just right. Also, thinking about how load-intensive your PHP code is is... well...

>>4
I initially created it for hosting that didn't have mod_gzip, the point depends on what the environment is. Even then mod_gzip would have to stat the original files often.

>>5
That's the thing, you just run it once to generate the files and Apache does all the work from httpd.conf directives or .htaccess files after that.

>>6
Oh noes, redundant statting. It's not like operating systems have inode caching, is it? Better leave cache replacement up to the system, since it's got a better total view of how shit is in the system as a whole.

Also, why on earth would you write something that is "run once", presumably on the server side, in PHP? That just cries "shit", "poop" and "ass" to me.

mod_gzip is mature and proven. Your PHP script is not. Your PHP script is also a PHP script.

>>7
Why does anyone write in PHP? Because it's more comfortable for a beginner/intermediate web developer and would be more accepted by such an audience.

Though I appreciate elitism now and then myself, I'm just looking for ideas on distribution.

>>8
Because it's more comfortable for a beginner/intermediate web developer
That's part of the problem. Programming languages shouldn't be comfortable to people who don't know how to program. PHP not only allows, but actively promotes sloppy code, which has already resulted in more than enough dumbfuckery in the world.

It is time to rid the world of PHP. That won't happen overnight, but not using PHP for new projects is a good start.

>>9
Sure, but until then I'd like some ideas on distribution. My code isn't sloppy, nor is it insecure(I assume someone would've brought that up eventually).

If you wish to disregard my script, fine. Just fire off some general code distribution ideas.

>>10
I suggest uploading it on your personal web space, creating a small and informative page that describes what it is and what it does, with good and clear documentation and a version history. Then just spam some relevant mailing lists and if your script is at all useful, it will shortly be widely used.

(Actually, I'm >>9 and I still think that this is a bad idea.)

>>10
>My code isn't sloppy, nor is it insecure

I hereby dub thee "Mr. Hubris".

Call for Mr. Hubris. Some Nemesis guy. Says it's urgent.

>>11
Really to me it doesn't matter what language does it as long as it gets the job done. Since this script will never see untrusted user input I thought PHP would be best seeing it'd help those with limited bandwidth on cost-effective hosting, which 99.99% of the time has PHP and 90% of the time has mod_rewrite.

TREVOR?

>>14
Haha. It's probably true too.

>>14
Hehe, no. My name isn't Trevor. But, thanks to everyone that felt like responding. I found the responses somewhat humourous and somewhat informative.

Since this script will never see untrusted user input I thought PHP would be best seeing it'd help those with limited bandwidth on cost-effective hosting, which 99.99% of the time has PHP and 90% of the time has mod_rewrite.
Uh, hey... have you ever run anything on shared hosting?

There's a big problem with your program here: shared hosting is almost always lot tighter about CPU usage than bandwidth.  Invoking a PHP script, even if you're returning a cached gzip, will get you running into CPU time limits far, far, far sooner than you're be bumping into bandwidth limits.

Let's take a look at what your PHP script would be used on. Would it be used on bandwidth-intensive media files? No, because they don't compress. Would it be used on things like HTML? Why yes! Except that... HTML, text, et al take very little bandwidth to begin with.

So, like, unless you're running a dedicated host with a 1GB bandwidth cap, this isn't useful. Since such hosts don't exist, the idea was interesting but ultimately completely unusable in the real world.

I hope you learned something from it though.

Also,

90% of the time has mod_rewrite.

From my experience, it's less than half, actually. And if they have mod_rewrite, chances are they have mod_gzip or mod_deflate too.

http://schroepl.net/projekte/mod_gzip/cache.htm

>>17
The script is run-once, the httpd handles if the requested version is gzip'd or not via httpd.conf, or more much more likely, .htaccess files. I don't see any significant increased resource use. It'd be less load-intensive than dynamically gzip'd PHP pages, even.

>>18
Well, even then you can at least specify different compression levels to suit the content being sent. Level 1 for files that don't compress well and you wouldn't want clients taking too long decompressing.

>>20
Premature optimization.

>>21
The root of all e-Bills amirite?

>>20
If it doesn't compress well, that's probably because it's ALREADY COMPRESSED.

This whole thread is stupid. mod_gzip exists if you want dynamically gzipped content. If you want to make it unnecessarily more complicated than it needs to be, just fucking gzip it yourself.

>>23
I'm talking about using it for static content like .js and .css files, some are more redundant than others(minified, for instance).

That's what the script does, minus the fucking. It makes copies of the files in a directory that are browser-readable gzip'd and creates the .htaccess files so the right version is sent. It's not that complicated at all.

This place seems like /. jr. for some reason.

After a bit of thought, I've decided this isn't a completely bad idea if you're stuck on a shitty host without mod_gzip/deflate (and there are quite a few of them).

If you're using mod_rewrite rules it isn't particularly expensive.