I can do an IRC chat, just name the time and place,<br><br>Toby<br><br><div class="gmail_quote">2009/6/8 Alex Wulms <span dir="ltr"><<a href="mailto:alex.wulms@scarlet.be">alex.wulms@scarlet.be</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi all,<br>
<br>
The updated version of the http-crcsync standard/discussion paper is in the<br>
git repository at:<br>
<a href="http://repo.or.cz/w/httpd-crcsyncproxy.git?a=blob;f=crccache/doc/http_crcsync_protocol.odt;h=26c746a1a97fb4edeea37ed1d6ce8bb19638a03e;hb=49dd514544163bccc8be33bdee61603ea5664cbd" target="_blank">http://repo.or.cz/w/httpd-crcsyncproxy.git?a=blob;f=crccache/doc/http_crcsync_protocol.odt;h=26c746a1a97fb4edeea37ed1d6ce8bb19638a03e;hb=49dd514544163bccc8be33bdee61603ea5664cbd</a><br>
<br>
There are still a few open points:<br>
- Number of hashes<br>
- Hash size<br>
- Re-apply original content-encoding or not on the re-constructed entity?<br>
- How to indicate an error in the re-constructed entity to an HTTP 1.0 client.<br>
<br>
I would appreciate your input (especially of Toby, Tridge and Rusty) on these<br>
open points. How about discussing them next weekend on some irc channel, to<br>
get them closed?<br>
<br>
Kind regards,<br>
Alex Wulms<br>
<br>
<br>
Op donderdag 4 juni 2009, schreef Alex Wulms:<br>
<div><div></div><div class="h5">> Hi everybody,<br>
><br>
> Toby and I have recently discussed below idea of making http-crcsync an<br>
> extension to RFC3229. We both believe it makes a lot of sense. If nobody<br>
> objects, I'll start updating the protocol description document this Sunday<br>
> accordingly after which Toby and I can fully align the Apache based code as<br>
> well. Please note that Toby already implemented a first step in this<br>
> direction, in order to experiment returning a 226 in stead of 200 response<br>
> code with Apache.<br>
><br>
> Pedro,<br>
><br>
> Please don't let this protocol finetuning stop you from starting your work<br>
> on the firefox client. The core of the protocol (e.g. the http-crcsync<br>
> response body) will remain unchanged.<br>
><br>
> Cheers,<br>
> Alex<br>
><br>
> Op woensdag 13 mei 2009, schreef Toby Collett:<br>
> > Hi Alex,<br>
> > Finally got a chance to read this. Is a good description of the<br>
> > problem/scope.<br>
> ><br>
> > I have a question for all with regard to RFC3229. It would be entirely<br>
> > possible for us to design the http-sync to be an extension of RFC3229,<br>
> > basically add a new conditional request if-blocks-match or something of<br>
> > the like, and expect a response with 226 instance coding applied.<br>
> ><br>
> > If we take this approach then our block encoding just becomes a standard<br>
> > instance coding. The presence of a if-blocks-match header can be taken to<br>
> > imply an accepts instance coding 'blocks' or whatever we call it to save<br>
> > sending redundant information.<br>
> ><br>
> > The question then becomes, is it worth the effort, the last lot of<br>
> > traffic I saw in a quick google search on rfc3229 was in 2004 with regard<br>
> > to blogs and so on. So it is not widely deployed. On the other hand with<br>
> > careful design of our protocol we can be compatible, so is there a reason<br>
> > not to do it?<br>
> ><br>
> > Also a minor note, rather than having a small trailing block, why dont we<br>
> > just add the trailing data to the last large block, this way we dont end<br>
> > up with a hash thats almost the size of the block it represents (or in<br>
> > some cases bigger)<br>
> ><br>
> > Toby<br>
> ><br>
> > 2009/4/29 Alex Wulms <<a href="mailto:alex.wulms@scarlet.be">alex.wulms@scarlet.be</a>><br>
> ><br>
> > > Hi,<br>
> > ><br>
> > > Please find in attachment my current ideas on the http-crcsync<br>
> > > protocol.<br>
> > ><br>
> > > I hope you don't mind but I have drafted the paper in open office and<br>
> > > not as a<br>
> > > plain text file. An open office version makes it easier to visibly<br>
> > > divide the<br>
> > > document in logical sections in order to enhance the readability and<br>
> > > the structure. Though, I have added a text export for convenience, in<br>
> > > case somenone might not have OO available.<br>
> > ><br>
> > > As I mentioned yesterday in this list, the paper is based on the<br>
> > > insights that<br>
> > > have grown while working on the crccache proxy modules and after<br>
> > > studying the<br>
> > > various papers on delta-encoding (the RFC, Toby's draft and the<br>
> > > protocol proposal on the original rproxy site) and everything related<br>
> > > to it.<br>
> > ><br>
> > > Like Toby proposed, maybe it would make sense to convert this into a<br>
> > > wiki and<br>
> > > continue the work there. What do you think?<br>
> > ><br>
> > > Cheers,<br>
> > > Alex<br>
> > ><br>
> > > Op maandag 6 april 2009, schreef <a href="mailto:tridge@samba.org">tridge@samba.org</a>:<br>
> > > > Hi Toby,<br>
> > > ><br>
> > > > > This is transmitted in two forms. One is an SHA1 hash of the<br>
> > > > > complete chached file, and the other is a set of block hashes.<br>
> > > ><br>
> > > > ...<br>
> > > ><br>
> > > > > Content-Hash:<br>
> > > > > This will be an sha1 hash of the entire cached body, and will<br>
> > > > > allow<br>
> > ><br>
> > > the<br>
> > ><br>
> > > > > server to transmit deltas based on its knowledge of past versions<br>
> > > > > of<br>
> > ><br>
> > > the<br>
> > ><br>
> > > > > page.<br>
> > > ><br>
> > > > How do you imagine that this hash would be used? I don't think it is<br>
> > > > practical to think that servers would keep a record of all the<br>
> > > > dynamic pages they have been served out, and for static pages I think<br>
> > > > the normal cache tag mechanisms already work well.<br>
> > > ><br>
> > > > I think a SHA1 or similar of the servers generated page is really<br>
> > > > worthwhile, but a whole file hash of what the client has in cache<br>
> > > > doesn't gain anything that I can see.<br>
> > > ><br>
> > > > btw, I also wonder if you've seen this:<br>
> > > ><br>
> > > > <a href="http://www.ietf.org/rfc/rfc3229.txt" target="_blank">http://www.ietf.org/rfc/rfc3229.txt</a><br>
> > > ><br>
> > > > That is the result of earlier efforts to standardise delta encoding<br>
> > > > in HTTP. I was a little bit involved in that effort, although it<br>
> > > > concentrated on storing old copies on the server, which I wasn't<br>
> > > > interested in.<br>
> > > ><br>
> > > > Still, it should provide some very useful background to the current<br>
> > > > effort.<br>
> > > ><br>
> > > > Cheers, Tridge<br>
> > > > _______________________________________________<br>
> > > > Http-crcsync mailing list<br>
> > > > <a href="mailto:Http-crcsync@lists.laptop.org">Http-crcsync@lists.laptop.org</a><br>
> > > > <a href="http://lists.laptop.org/listinfo/http-crcsync" target="_blank">http://lists.laptop.org/listinfo/http-crcsync</a><br>
><br>
> _______________________________________________<br>
> Http-crcsync mailing list<br>
> <a href="mailto:Http-crcsync@lists.laptop.org">Http-crcsync@lists.laptop.org</a><br>
> <a href="http://lists.laptop.org/listinfo/http-crcsync" target="_blank">http://lists.laptop.org/listinfo/http-crcsync</a><br>
<br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>This email is intended for the addressee only and may contain privileged and/or confidential information<br>