ag.ml2007 at zirona.com
Tue Sep 18 15:51:50 GMT 2007
On Tue, 2007-09-18 at 09:58 -0500, Otto wrote:
> While I see the benefits of the idea, I'm not sure how useful it will
> actually be in this particular case. Looking at the SVN:
> -jQuery is already packed code.
> -TinyMCE gets gzip compressed if the browser supports it (examine
> -There's various pre-made packed versions of Prototype and
> Scriptaculous if you need them, best to use those instead of rolling
> your own. Or better yet, wrap them into gzip.
If the code is already packed so much, how could I come out with
reducing the size by 50% with that other packer? ;-)
> as a bit silly. You'd be better off creating a static *.gz version of
> the file and having the web server serve that directly. Of course,
> that's only "easy" with either Apache 1.3 and mod_gzip or Apache 2.2
> and mod_deflate+mod_filter, but still, it's more of a server thing.
Not exactly. Mod_gzip and others deflate the file, while they do not
reassemble the code itself. Have a look at one of the packed files (e.g.
at the MooTools download page) to see what is meant by packing the JS
code. It is possible to combine compression and packing to get even
> Essentially what I'm saying is that the WordPress package should
> really only include a) pre-packed versions of code from the actual
> code providers, or b) some easy way to configure it to use server
> features for compression.
I think that if a WordPress-based packaging turns out to be efficient,
secure (in the sense of code integrity) and easy maintainable,
WP-internal packing should really be considered.
> Actually distributing packed versions in the core just seems like a
> bad idea in the long run. It's modifying these standard libraries, and
> while it might not break core code, it could break plugins wanting to
> use those libraries and which are expecting them to work like the
> originals do, without fail.
The standard libs would still be provided as source. And plugins will
still be able to use the packed libraries, as the function names and
public variables are preserved. If they weren't, the compression would
be completely senseless in the first place.
However, maybe it would be possible to provide the WP admins the option
to chose whether they want the JS compressed or not. If they don't want,
the src file will be delivered.
Alex Günsche, Zirona OpenSource-Consulting
Blogs: http://www.zirona.com/ | http://www.regularimpressions.net
PubKey for this address: http://www.zirona.com/misc/ag.ml2007.asc
More information about the wp-hackers