Whatever happened to maximizing usability? Most AVIs can be compressed by a further 1%. This means that we save a significant amount of insertion time at very little cost. And for those files which are really compressible (e.g. a large HTML file) we can make huge savings. We have to do this anyway for freesites, I don't see the problem with doing it for individual files.
The client shouldn't have to care about this, it's the node's job, because it's functionality that EVERY client will need and therefore is a logical part of the node, since FCPv2 is a deliberately high level API designed to do as much as possible of the work for the client author. Doing it on the client will just lead to a mass of incompatible standards, and more (duplicated) work for client authors. On Sat, Aug 12, 2006 at 09:15:18AM -0700, Ian Clarke wrote: > Firstly, having the double negative is silly, the parameter should be > "Compress=true/false", rather than "DontCompress". > > Secondly, I really don't think we should be compressing files by default > - most file formats used for large files (images, movies, audio etc) are > already compressed, and trying to compress them further will be a waste > of time. > > Compression and decompression of content is something that should be > handled by the user or FCP client, not by the node, since the client is > better suited to determine an appropriate compression format given the > file type. > > Ian. > > On Sat, 12 Aug 2006 14:12:47 +0100, "Matthew Toseland" > <toad at amphibian.dyndns.org> said: > > I think we should try to compress (gzip) all inserted files unless > > explicitly asked not to via DontCompress, and that the insert form > > should default to dontcompress=false. My justification for this is > > simply that: > > - If we set the default to DontCompress=true, we will have to maintain a > > registry of uncompressible mime types, because some data is > > really compressible, and that data will be radically smaller (and > > therefore faster) to insert. > > - Even for AVIs, for example, gzip will usually squeeze out an extra 1% > > or so. 1% of 700MB is 7MB. Inserting an extra 7MB will probably take > > longer than the time it takes to gzip 700MB. > > -- > > Matthew J Toseland - toad at amphibian.dyndns.org > > Freenet Project Official Codemonkey - http://freenetproject.org/ > > ICTHUS - Nothing is impossible. Our Boss says so. > _______________________________________________ > Tech mailing list > Tech at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > -- Matthew J Toseland - toad at amphibian.dyndns.org Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20060812/13c3e296/attachment.pgp>
