- From: Eric Prud'hommeaux <eric@w3.org>
- Date: Fri, 21 Mar 2014 15:50:10 -0400
- To: Henry Story <henry.story@bblfish.net>
- Cc: public-ldp <public-ldp@w3.org>, Linked Data Platform WG <public-ldp-wg@w3.org>
- Message-ID: <CANfjZH2aa8+qhA0_YscSMnS6OE4L1f3YtssVwpzWS4fR0Rr1OQ@mail.gmail.com>
On Mar 21, 2014 8:38 PM, "henry.story@bblfish.net" <henry.story@bblfish.net> wrote: > > During the last conf call the 209 issues were discussed. > > http://www.w3.org/2013/meeting/ldp/2014-03-17#209 > > The logs don't make it clear who was speaking, and a lot of the arguments seem to be missing. > I understood that it was Erik Wilde who was reporting back form the London IETF meeting. > He reported back that one pushback ( from whome ? ) was that SPDY or HTTP2 allowed the > server to send back responses to documents that had not been requested by the client, and > that this could solve the 209 problem. Essentially the server could just send back a document > ( but only from the same server ) that was the one requested, without the client asking for > it. This seemed interesting, but it would be nice to have a link to the passage in the RFC > for where this is specified. > > It seemes odd to me that this feature could be generally made available > without requiring the server to keep a lot of state about the client and what it had received. > For example if we looka at all the 303s used by the foaf ontology, every foaf term redirects > to the ontology document. The server would have to keep track of each client to know > that it had allready received the document, before sending it again. That seems odd. It may be odd for SPDY in general, but less so for our use case. Recall that all we really hope to achieve with 209 is to reduce from two round trips to one, even at the cost of a potential cache miss for multiple redirects to the same resource. Any even partially effective cache "prediction" in SPDY would only be of benefit to us. > Henry > > > Social Web Architect > http://bblfish.net/ > >
Received on Friday, 21 March 2014 19:50:38 UTC