View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0010603||mantisbt||attachments||public||2009-06-18 02:52||2020-01-27 14:36|
|Summary||0010603: Automatic compression of uploads for download|
Quite often we have attachments that are pretty big, no problem on the home site but on more remote sites pretty annoying.
|Steps To Reproduce|
Compression routine, build upon php_zip, would look something like:
Updated synopsis. Your report completely differs from your summary.
That's a good idea. We now need a patch for this with the appropriate configuration knobs / documentation updates. Here are my thoughts:
At one point we were also considering auto-conversion of formats like bmp to an impage format with better compression. It would be interesting comparing the zip of a zipped bmp with the size of a jpg, gif, etc.
Personally I would vote for one compression mechanism, no flag in the DB, set a minumum size , an on/off option and excludes.
I believe that a flag is required for the following reasons:
I agree with 1 compression mechanism (as I mentioned in my earlier comment, this may be an overkill).
I don't really see a need for this when we can just use gzip compression for server <-> client communication. The limiting factor is almost never going to be the amount of disk space you have available to serve up files - it'll be CPU usage and memory consumption... and zip compression certainly doesn't help limiting those two factors. Unless of course you're trying to save space in the database... in which case, isn't there an on-the-fly approach we can use in PHP to do this (as opposed to writing zip files to the disk and reading them back)?
Still, I would disagree with compressing files because of CPU usage concerns and the availability of better traditional solutions such as mod_gzip, etc.
For me it is not about diskspace, it is about the time it takes to view a bmp-file on a remote location. They sometimes are over 2mb whereas compressed they might be just 50k.
I would vote for a one off additional process of zip/unzip for all existing bug attachments too. When a project uses a lot of text files (xml) like Scribus, we have a lot of them sitting around that could be made a lot smaller for all historical bugs, as well as turning on the compression for new bugs.
Another vote for this feature.
|2009-06-18 02:52||cas||New Issue|
|2009-06-19 07:55||siebrand||Note Added: 0022194|
|2009-06-19 07:55||siebrand||Summary||Large Attachments => Automatic compression of uploads for download|
|2009-06-19 18:35||vboctor||Tag Attached: patch|
|2009-06-19 18:39||vboctor||Note Added: 0022201|
|2009-06-19 18:39||vboctor||Status||new => acknowledged|
|2009-06-23 03:05||cas||Note Added: 0022231|
|2009-06-23 03:09||cas||Note Edited: 0022231||View Revisions|
|2009-06-23 03:37||vboctor||Note Added: 0022235|
|2009-06-23 06:21||dhx||Note Added: 0022237|
|2009-06-23 09:46||cas||Note Added: 0022242|
|2009-07-04 17:31||vboctor||Relationship added||has duplicate 0006835|
|2009-07-04 17:34||vboctor||Category||feature => attachments|
|2009-07-04 17:50||cbradney||Note Added: 0022392|
|2009-07-04 18:40||cbradney||Note Edited: 0022392||View Revisions|
|2020-01-27 14:36||sandyj||Note Added: 0063521|