On 12 Aug 2006, at 12:36, Matthew Toseland wrote: > Whatever happened to maximizing usability?
Imposing a compression format that may be ill suited to what is being inserted doesn't maximize usability, it simply means that the node is meddling in a client issue in which it lacks the competence to meddle. I can't think of any other data transmission software that takes it upon itself to compress data by default, about which it knows nothing, by default (BitTorrent doesn't, Secure Copy doesn't, LimeWire doesn't, Kazaa didn't, even Apache doesn't). > Most AVIs can be compressed by a further 1%. I doubt it, except perhaps for small AVIs, and I certainly doubt that this is true of most compressed video formats. Generally speaking information theory tells us that compressing data that has already been compressed is rarely effective. > 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. I'm not arguing against the value of compression, I'm just arguing against the node doing it. Different types of compression are appropriate for different file types, it doesn't make sense for us to impose one type of compression, that happens to be optimized for text and some binary formats, on all data types. The client has the expertise to decide on the appropriate format in which to insert content, we don't. > We have to do this anyway for freesites, I don't see the > problem with doing it for individual files. With freesites we provide the client, and therefore we do have the expertise to determine the appropriate form of compression. This logic doesn't generalize to all content that might be inserted into Freenet, which will include many types of data where gzip/bzip2/7zip are not an appropriate compression algorithm). > 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, Rubbish, clients that deal with anything other than text or binary data will not need this kind of compression. It makes no sense to impose a single type of compression across all data that might be inserted into Freenet - this should be left to the client which understands what data they are dealing with and the best format for it. > since FCPv2 is a deliberately high level API > designed to do as much as possible of the work for the client author. Yes, but not such that it imposes a uniform solution across all clients where different solutions are needed for different clients. > Doing it on the client will just lead to a mass of incompatible > standards, and more (duplicated) work for client authors. If by "incompatible" you mean using jpeg to compress an image rather than gzip, or mpeg to compress a video rather than bzip2, then sometimes incompatibility is justified. Now I have presented an argument for why we shouldn't support in-node compression of data at all, but I'm willing to compromise and agree to it provided that it isn't enabled by default. This way, client authors can use it if they deem it appropriate, but are much less likely to use it where it isn't. Ian. Ian Clarke: Co-Founder & Chief Scientist Revver, Inc. phone: 323.871.2828 | personal blog - http://locut.us/blog -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20060812/6dac6ae9/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20060812/6dac6ae9/attachment.pgp>
