Mh. to me it sounds like you want to implement from scratch a data compression algorithm. But there are a lot very efficient out there and I bet they're already used in data transmission over network. Don't you just reinvent the wheel
On Tue, Sep 29, 2009 at 5:25 PM, Bernd <[email protected]>wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
