Re: (Dis)Proving that 303s have a performance impact.

On 17 February 2013 22:43, Mo McRoberts <Mo.McRoberts@bbc.co.uk> wrote:

>
> On Sun 2013-Feb-17, at 17:35, Kingsley Idehen <kidehen@openlinksw.com>
> wrote:
>
> > If you need to retrieve the data the describes the entity denoted by the
> Linked Data URI. Likewise, when you try to retrieve data that describes a
> specific entity denoted by a hash HTTP URI you end up retrieving the
> description of the entity and the description its descriptor i.e., the
> content retrieved is a combination of the document subject and the document
> itself.
> >
> > Whenever you move from the theoretical to the practical by making a
> Linked Data browser (or something like that) you'll see the futility in
> your argument, until then I leave you to continue deflecting by references
> to specs etc..
>
> Having implemented these things, I'm still failing to understand what on
> earth you're talking about, in part because you refuse to take the time to
> write in comprehensible sentences.
>
> It's really, REALLY, simple:—
>
> 1. Best practice (and it does indeed work in practice, as you know) is
> that one uses different URIs for the document and the thing that is
> described by that document. From experience, I know that this is not
> obvious to those who may be very capable programmers but haven't lived and
> breathed linked data for long.
>

I think there is an education gap but in today's world to be a 'capable
programmer' you need to understand the basics of the web.  And that means
to understand the basics of URI, HTTP and HTML in that order.  For example,
I have spoken to the people behind tent.io, and they dont grok # URIs at
all, and are barely aware of their existence.  We really need to think of
ways to close this education gap, perhaps the webid spec will be a tool in
this respect.


>
> 2. In order to do that, there are two likely mechanisms: 303 redirects or
> hash URIs.
>
> 3. While preferences vary, the fact that a 303 redirect results in an
> additional HTTP request over an equivalent hash URI is a fundamental facet
> of the protocol.
>

I think you need to grok hash URIs before you can really leverage 303s to
full effect.


>
> 4. While it is obvious that anybody when asked "does a redirect introduce
> an additional request?" would answer in the affirmative, asking somebody
> who isn't entirely familiar with the httpRange-14 debate “which tends to be
> simpler and more efficient, hash or hashless URIs?" in this context isn't
> likely to yield as quick an answer.
>

Efficiency seems to me to be out of scope at this level of discussion.  The
benefit of WebID is clean modular separation of concerns, which universal
interoperability.  We've mixed up the narrative by crossing architecture,
advocacy and implementation details.


>
> 5. There is nothing wrong, unusual, strange or otherwise about including
> best-practice guidance in non-normative parts of a spec. In fact, the
> opposite.
>
> 6. Given that WebID isn't making hash-based URIs a MUST (and nor should
> it, IMHO), and given that the spec shouldn't really require top-to-bottom
> knowledge of the entire semweb ecosystem, it is entirely sensible and
> normal to include guidance which explains the above and provides sufficient
> information to make a decision without acres of research.
>

It was Tim that proposed making URIs a MUST as a tactic to get it to REC
status.  It was widely supported at TPAC, tho of course some advanced use
cases do have 303s as beneficial as has been pointed out.  It's not going
to be possible to exclude their usage or allow the test suites to fail
them.  But if you're going to use 303s effectively, you probably know what
you're doing anyway.


>
> 7. I would caution against relying solely on the presence of hash-based
> URIs in the examples to make the point — as the old saying goes, “a little
> knowledge is a dangerous thing”, and it's entirely likely that developers
> unfamiliar with httpRange-14 and its ilk would read them and, lacking any
> other information about it, draw the conclusion that the fragid is
> superfluous.
>

Why would people consider the fragid superfluous ... would not a new comer
to a technology simply cut and paste an example to get going?


>
> 8. Those who are knowledgeable enough not to need the guidance can ignore
> it.
>

+1


>
> So really, it boils down to whether the consensus is that having a
> guidance note (not necessarily with the current wording) explaining 1…3
> above is on balance harmful or beneficial.
>
> (My personal view is that if the consensus is 'harmful', there are
> probably bigger problems here than this specific issue).
>

I think there's a big need to explain 1-3 to a wider audience ... but maybe
this is the job of the TAG / W3C / AWWW, rather than in this spec...


>
> M.
>
> --
> Mo McRoberts - Technical Lead - The Space
> 0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E,
> Zone 1.08, BBC Scotland, Pacific Quay, Glasgow, G51 1DA
> Project Office: Room 7083, BBC Television Centre, London W12 7RJ
>
>
>
> -----------------------------
> http://www.bbc.co.uk
> This e-mail (and any attachments) is confidential and
> may contain personal views which are not the views of the BBC unless
> specifically stated.
> If you have received it in
> error, please delete it from your system.
> Do not use, copy or disclose the
> information in any way nor act in reliance on it and notify the sender
> immediately.
> Please note that the BBC monitors e-mails
> sent or received.
> Further communication will signify your consent to
> this.
> -----------------------------
>
>