Re: hash in WebID - cachability problem

On 4 Dec 2012, at 19:47, Ted Thibodeau Jr <tthibodeau@openlinksw.com> wrote:

> 
> On Dec 2, 2012, at 12:25 PM, Henry Story wrote:
> 
>> But now I wonder how that fits with Ted Thibodeau's position
>> on the KeyChain [1]. If  I take your argument above and replace
>> Tabulator by OSX Keychain bug ( as shown in this picture
>> http://tinyurl.com/cpbpcqe  ) we get the following:
>> 
>>> neither Linked Data, WebID nor the AWWW are about the KeyChain
>>> or any other product for that matter. There's no news about
>>> the challenges posed to clicking on the SAN of the Apple OSX
>>> Keychain. That's too solution specific to be used as an
>>> argument *against* staying with IETF findings re., standards
>>> that affect other Web-scale Linked Data endeavors .
>> 
>> Assuming that the clicking on the OSX keychain SAN URI is not
>> more important than the Tabulator Project, as far as Linked
>> Data goes, then it seems that your argument above (which I
>> think is a good one - and which TimBL needs to address  in
>> more detail than I was able to do) requires you to apply that
>> argument back to your OSX keychain. 
> 
> Suggesting that "it's hard(er) to implement some functionality
> when WebID permits non-hash URIs" is not the same as saying "this 
> tool does this troublesome thing when WebID uses a hash URIs".

People who do real implementations of Linked Data in javascript 
on the browser are telling us this is problematic for them: speed
matters in user interface, and the 303 is creating real usability
issues.

The OSX Keychain argument you deploy with such insistence is a bug
against the URL, URI, and IRI specs, and there furthermore is no
use case that would ever make it widely adopted - as it is way too
geeky to go and look at that part of the keychain.

> 
> 
> As Nathan says --
>> [[
>>> RFC 2616 says:
>>> "The 303 response MUST NOT be cached, but the response to
>>> the second (redirected) request might be cacheable."
>>> 
>>> HTTPBis says:
>>> "A 303 response SHOULD NOT be cached unless it is indicated
>>> as cacheable by Cache-Control or Expires header fields."
>>> 
>>> Of course most tooling will not cache 303s as it's been
>>> a MUST NOT for 13+ years.
>> ]]
> 
> 
> Initial RFC 2616 client sequence is --
> 
> 1. dereference <http://dbpedia.org/resource/Linked_Data>
> 2. receive 303 to <http://dbpedia.org/page/Linked_Data> 
>   (note that intervening machinery doesn't cache this result, 
>   and client proceeds to --)
> 3. dereference <http://dbpedia.org/page/Linked_Data>
> 4. receive document 
>   (note that intervening machinery caches *that*, associated 
>   with <http://dbpedia.org/page/Linked_Data>, and *not*
>   with <http://dbpedia.org/resource/Linked_Data>)
> 
> Future RFC 2616 sequence --
> 
> 1. dereference <http://dbpedia.org/resource/Linked_Data>
> 2. receive 303 to <http://dbpedia.org/page/Linked_Data>
> 3. dereference <http://dbpedia.org/page/Linked_Data>
> 4. receive 200 OK and previously cached document

yes, that is indeed what I understood of Nathan's proposal.
Where 2 can be a cached result ( which means your browser can
go to your hard drive to fetch the info, and does not need to
go all the way to the remote server )

> 
> The differences under HTTPbis are relatively small.  The 303 
> result *might* be cached -- *if* Cache-Control or Expires header
> say so -- and so a few machine interactions might be saved, but
> the end result will be the same.


The caching possibility does make things more palatable engineering
wise for HTTPBis. But I can not find any reference to it in the very
voluminous HTTPBis docs. As soon as someone points me to it, I'll add
it to the wiki.

> 
> 
> Now, in the WebID world, which the above isn't quite...
> 
> When I dereference the /page/ URI, I get a document back.
> That document could include statements like --
> 
>   <http://dbpedia.org/resource/Linked_Data>
>      :describedBy
>         <http://dbpedia.org/page/Linked_Data>
> 
> -- and, depending on my WebID-aware application, and interaction
> with the user, and other decisions, I might make note of that -- 
> such that in future, my default lookup is not 
> <http://dbpedia.org/resource/Linked_Data>, but the document
> which I know to describe that entity, i.e.,
> <http://dbpedia.org/page/Linked_Data>.
> 
> 
> Henry, you said:
> "HttpBis requires cache control headers"

( yes, I meant "HTTPBis require cache control headers if you wish to 
 have your redirect metadata cached )

> 
> That's not accurate.  HTTPbis *allows* Cache-Control and 
> Expires headers to be taken into account when decisions are
> made about whether or not to cache a 303 result.

I am still looking for a pointer to where it says this.

> 
> Will DBpedia-on-Virtuoso include those headers in future?  
> 
> All but guaranteed, once HTTPbis reaches sufficient stability, 
> and this update gets high enough on our implementation priority 
> list for Virtuoso.
> 
> (Note -- "DBpedia" is not the same as "OpenLink", but the public
> server face of DBpedia is mostly Virtuoso...)
> 
> 
> You also say,
> "If the dbpedia folks can't even get these basic engineering 
> right..."
> 
> by which you're really targeting OpenLink and Virtuoso, of
> which fact I'm sure you're aware.

Sorry I thought at the time that these HTTPBis redirects
where widely adopted already. 

> 
> Now let me be clear.  "Basic engineering" means conformance with
> today's active standards and specifications.

Good to hear this. 


> 
> Today's active standard is HTTP 1.1 -- not HTTPbis.
> 
> To my mind, "basic engineering" also includes basic efficiency -- 
> i.e., leave out that which is not necessary.  Lighten the load 
> you're putting on shared infrastructure as much as you can.
> 
> Cache-Control and Expires headers are not relevant to 303s, 
> under HTTP 1.1 -- so why would we include these in the traffic 
> we put across the net, today?
> 
> 
> I think I'm all caught up on this thread now.... 
> 
> Ted
> 
> 
> 
> --
> A: Yes.                      http://www.guckes.net/faq/attribution.html
> | Q: Are you sure?
> | | A: Because it reverses the logical flow of conversation.
> | | | Q: Why is top posting frowned upon?
> 
> Ted Thibodeau, Jr.           //               voice +1-781-273-0900 x32
> Senior Support & Evangelism  //        mailto:tthibodeau@openlinksw.com
>                             //              http://twitter.com/TallTed
> OpenLink Software, Inc.      //              http://www.openlinksw.com/
>         10 Burlington Mall Road, Suite 265, Burlington MA 01803
>     Weblog   -- http://www.openlinksw.com/blogs/
>     LinkedIn -- http://www.linkedin.com/company/openlink-software/
>     Twitter  -- http://twitter.com/OpenLink
>     Google+  -- http://plus.google.com/100570109519069333827/
>     Facebook -- http://www.facebook.com/OpenLinkSoftware
> Universal Data Access, Integration, and Management Technology Providers
> 
> 
> 
> 
> 
> 
> 

Social Web Architect
http://bblfish.net/