[dev] [cvs] commit: imp compose.php contacts.php login.php mailbox.php message.php search.php imp/templates/compose javascript.inc imp/templates/contacts javascript.inc imp/templates/javascript compose.js contacts.js login.js mailbox.js message.js search.js ...

[Michael M Slusarz]

Quoting Jan Schneider <jan at horde.org>:

> Zitat von Michael M Slusarz <slusarz at curecanti.org>:
>
>> slusarz     2006-02-10 14:05:18 PST
>>
>>   Modified files:
>>     .                    compose.php contacts.php login.php
>>                          mailbox.php message.php search.php
>>     templates/javascript/src addressesBlocks.js folders.js
>>                              popup.js
>>   Added files:
>>     templates/javascript compose.js contacts.js login.js
>>                          mailbox.js message.js search.js
>>     templates/javascript/src compose.js contacts.js login.js
>>                              mailbox.js message.js search.js
>>   Removed files:
>>     templates/compose    javascript.inc
>>     templates/contacts   javascript.inc
>>     templates/login      javascript.inc
>>     templates/mailbox    javascript.inc
>>     templates/message    javascript.inc
>>     templates/search     javascript.inc
>>   Log:
>>   Move all javascript specific files to templates/javascript/src.
>> Allows us to
>>   1) compress JS code, 2) keep javascript files separate from presentation
>>   files.
>>   Add header comments to all JS files.
>
> The problem with compressed files in templates/javascript is that it's
> getting hard to debug them, which was possible with the js/ files
> through setting the jsuri parameter in registry.php.
> I'm not sure if it's really necessary to compress all js files either,
> the bandwidth gain shouldn't be that huge for most of the files.

Points well taken.  I think we should kind of use IMP HEAD as the  
testing ground for this for awhile to see if it truly is worthwhile.

Arguments for:
* It makes looking through HTML code _much_ easier, as you don't have  
to wade through 300 lines of javascript between the presentation  
elements.
* Not all sites support compression, and not all browsers handle it,  
so this provides an additional way for us to save some bandwidth (not  
to mention js compression is much less resource intensive than  
on-the-fly compression)
* A lot of these javascript files are not able to be cached, since  
they are being output inline.  And if we can save 20-40% of the size  
of this data by compression, that comes out to be quite a bit of  
potential bandwidth savings.  Example: compression of the mailbox  
javascript saves 5K per pageload.  Say a user checks his mailbox 10  
times per session.  This is 50KB of saved bandwidth.  If 20,000 users  
login on a single day, that is 1GB of savings (without page  
compression benefits, of course).

If the main argument against not-compressing is debugging, I  
personally think that is a weak argument.  Anwyay, we could just do  
something like defining a 'IMP_JAVASCRIPT' variable that could easily  
be changed by the few people (i.e. the devs) that are actively  
debugging the js code.

michael

_______________________________________
Michael Slusarz [slusarz at curecanti.org]