Hi, having taken interest in the Courgette project (http:// dev.chromium.org/developers/design-documents/software-updates- courgette), I wanted to provide an idea of mine which I had in my head for a couple of years. What I am proposing here is probably neither new, nor may it be effective in most cases. On the contrary, it is probably only effective in some edge or special cases, if at all.
Also, there are still a lot of problems to be figured out with it. Especially the "fitness function" for evaluating interesting bit patterns to be used in the bitpattern library proposed is optimally determined by the content of the new file to be transferred... Anyway, I give it a spin, and would appreciate any kind of feedback on it, even if it something that has already been proposed by someone else. I am a freelance developer, self-taught, so forgive me my eventually missing background in theoretic matters... What I am proposing is a different way of transferring files (e.g. for upates for Chrome or any other application), in that the original file is *not* being sent bitwise over the network anymore, but recreated on the client computer from shared puzzle pieces (=data chunks in a shared bit pattern library) on the receiving client computer. For that to work, the sender and the client should be sharing a common pool of bitpattern strands (=e.g. chunks of data files found on the two computers, like operating system files for instance). The file to be sent is then analyzed by the sending computer, and chopped up into the biggest pieces which closest match entries in the bit patten library. The indices of the bitpatterns are then sent to the client, who rebuilds the file using the indices. This will generally not produce the final file yet, but only a "close match" to the final file to be sent. In a second step then, normal patching can occur and iron out bit errors left over from the first "coarse" file building step. Just to reiterate, I got a page in my presentation with an analogy describing the process: "These problems described here are similar to … finding the biggest matching puzzle pieces in two identical puzzle sets on sender and receiver computer which … closest describe file to be transferred, without rebuilding it identically (bitwise). Instead, the „closest match“ is being built with the available strands first. Then, in a second step, we transfer patch sets for the final bits in the rough draft to be corrected. (see „Courgette compression scheme by Google“ from hereon) Steps should therefore be: transfer description on how to build „closest“ match of file on target using generic bitpattern library, then in a second step, apply corrective set of mismatching bits using patches." I put together a PDF file describing the process at http://www.multimedial.de/share/BitPatternLibOverview.pdf Any feedback would be much welcome. The PDF is a draft, a work in progress, as I am still thinking this through. There are a lot of issues with it which I can't resolve myself due to missing knowledge, including the most basic one if this does work AT ALL. Other problems would include how to evaluatea decent set of bitpatterns for a general purpose bitpattern library. I am also thinking if a compiler could help this process in that it could produce bitpatterns on demand, based on most commonly used code patterns (e.g. loops and branches for instance, yet I am no machine language gure). Thank you very much for your consideration, Christophe Leske --~--~---------~--~----~------------~-------~--~----~ Chromium Discussion mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-discuss -~----------~----~----~----~------~----~------~--~---
