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

On 2/16/13 1:48 PM, Henry Story wrote:
> On 16 Feb 2013, at 19:26, Kingsley Idehen <kidehen@openlinksw.com> wrote:
>> On 2/16/13 1:11 PM, Henry Story wrote:
>>> On 16 Feb 2013, at 18:37, Kingsley Idehen <kidehen@openlinksw.com> wrote:
>>>> Yes, its got to be so simple that it won't take you time to make the entire experiment, and then present a set of conclusions drawn from your observations etc..
>>> What is the experminent we need to do? Can you describe it?
>> I don't have time for games. You outlined a set of claims upon which you've arrived at disputed conclusions. Thus, you already know the description of your experiment since you are the very same person that's provided its hypothesis.
> Ok, so we need to compare like with like, in order to be able to have an expermiment.
> So we put ourselves in a user's shoes.

Who is the WebID spec for? A user, a developer, or either?

>   He has to choose between either hash WebID,
> or a 303 WebID .

See comment above. In addition there's no "he" or "she" since a WebID is 
an HTTP URI that denotes an Agent.

> He has the same information to publish in both cases
>
> Hash:          http://joe.example/hash/joe#me
> Non Hash:      http://joe.example/resource/joe
>
> So we have the WebID and we need to get the WebID Profile document [1].
> Let us say the Profile document is of size S .
>
> A. Hash URL
> -----------
>
> A.1 Client does an HTTP GET on
>     http://joe.example/hash/joe
>   
> A.2 Client receives document of size S
>
>
> B. Non Hash URL
> ---------------
>
> B.1 Client does an HTTP GET on
>     http://joe.example/resource/joe
>
> B.2 Client received a 303 redirect to
>     http://joe.example/document/joe
>
> B.3 Client does an HTTP GET on
>      http://joe.example/document/joe
>
> B.4 Client received content of size S
>
>
> Conclusion
> -----------
>
> Given that the size of the documents are the same in both cases, and that we
> work with the same network speeds in order to remove accidental varations of speed,
> We see that B requires 1 more HTTP request to the server that A does.
>
> Therefore the difference in speed between A and B is exactly the difference of
> a message exchange. This difference will always exist no matter what the network
> setup.
>
> The noticeability of this will vary depending on the distance of the client to the
> server, and the size of the document. But it will always exist. There is therfore
> an efficiency gain to be had by choosing the hash url for free.
>
> Q.E.D.

Good for you, that isn't the issue at hand or the kind of experiment I 
seek, in line with my demos.

You should do the following, scoped to type of agent (human, 
organization, or some other mechanized entity that can dabble with the 
Web) or an agent that's publishing profile data at a Web accessible 
location that's to be associated with a WebID:

1. Make the data
2. Save the data
3. Publish the data .

Repeat as a data consumer seeking to determine relations between WebID 
and critical bits of profile data e.g., Public Key.

In all cases, everything should be live. None of this speculative stuff.

You have two choices: prove your case with empirical data, or save 
yourself and everyone else a lot of time by removing the unnecessary 
notice you've stuffed into a spec that's deteriorating (re. adoption by 
any serious Linked Data player) by the second....


Kingsley

>
> Henry
>
> [1] https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/identity-respec.html
> [2] ISSUE-74
>
> Social Web Architect
> http://bblfish.net/
>


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen