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

On 16 Feb 2013, at 21:33, Mo McRoberts <Mo.McRoberts@bbc.co.uk> wrote:

> this is the most ridiculous “debate” I've seen in a long time.
> 
> I can't honestly believe a non-normative *guidance* note is being objected to because some people may have situations where it's not sensible to follow the advice where they have enough information to do so, now how long it's dragged on for.
> 
> it's a fairly simple fact that in the case of WebIDs, nine times out of ten, a hash-based URI is going to be the sanest path for both producer and consumer; a developer shouldn't need to have to marshal the finer points of the whole hash-vs-hashless debate in order to arrive at a conclusion that they don't especially care about in the first place: those who have a preference will express it.
> 
> the persistence of this debate is actively harmful to the continued development of WebID. please just drop it and move on. call it a concession if you really must.
> 
> what next? arguing about the colours in the stylesheet used by the spec?

Thanks Mo,

 I did point out a few weeks ago, that I don't think the language in the spec
currently is good enough. It can be improved, and I would be happy for some 
proposals. Also I think that with some flesh around this section - eg. more on
what WebIDs are, this note will not loom large.


Henry


> 
> M.
> 
> On Sat 2013-Feb-16, at 20:24, Kingsley Idehen <kidehen@openlinksw.com>
> wrote:
> 
>> On 2/16/13 3:07 PM, Jürgen Jakobitsch wrote:
>>> henry, you continue to tune your examples in favour of your preference,
>>> that is not exactly scientific, hence my example.
>> 
>> +1000....
>> 
>> That's what he continues to pretend to not understand :-(
>> 
>> Henry: here's what you should attempt to produce, its the kind of stuff that comes from having implemented Linked Data rather that theorizing endlessly about it.
>> 
>> Links:
>> 
>> 1.  http://bit.ly/14YFd1o  -- a mixed bag of HTTP URIs that make the fundamental point: HTTP URIs are what matter, not the style (hash or hashless).
>> 
>> Kingsley
>>> 
>>> wkr turnguard
>>> 
>>> 
>>> On Sat, 2013-02-16 at 20:41 +0100, Henry Story wrote:
>>>> On 16 Feb 2013, at 20:29, Jürgen Jakobitsch <j.jakobitsch@semantic-web.at> wrote:
>>>> 
>>>>> hi,
>>>>> 
>>>>> if as "ferrari" constantly drives at 50mph and an old eastern german
>>>>> "trabant" [1] constantly drives at 50mph it can be concluded that
>>>>> ferraris and trabants are the same in performance.
>>>> Nice example. Let us adapt it to our case.
>>>> 
>>>> Say you receive a message that tells you where you can get some gold. So let us map our use cases to this
>>>> 
>>>> A: hash url
>>>>  go to London Paddington 22 and your find your gold there.
>>>> 
>>>> B: 303
>>>>  go to Japan and you'll find a message on where to get your gold there
>>>>  (namely in Paddington 22 in London )
>>>> 
>>>> 
>>>> Whichever car you use to get your gold, be it the east german trabant, or the ferrari,
>>>> it will clearly be faster if you receive a message of type A. That will save you a
>>>> trip to Japan, and back to London.
>>>> 
>>>> It's simple: Hash URLs are just more ecological, and they make you save time too.
>>>> 
>>>> :-)
>>>> 
>>>> Henry
>>>> 
>>>> 
>>>>> q.e.d.
>>>>> 
>>>>> :-D
>>>>> 
>>>>> wkr j
>>>>> 
>>>>> [1] http://en.wikipedia.org/wiki/Trabant
>>>>> 
>>>>> 
>>>>> On Sat, 2013-02-16 at 19:48 +0100, 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. He has to choose between either hash WebID,
>>>>>> or a 303 WebID . 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.
>>>>>> 
>>>>>> Henry
>>>>>> 
>>>>>> [1] https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/identity-respec.html
>>>>>> [2] ISSUE-74
>>>>>> 
>>>>>> Social Web Architect
>>>>>> http://bblfish.net/
>>>>>> 
>>>>> --
>>>>> | Jürgen Jakobitsch,
>>>>> | Software Developer
>>>>> | Semantic Web Company GmbH
>>>>> | Mariahilfer Straße 70 / Neubaugasse 1, Top 8
>>>>> | A - 1070 Wien, Austria
>>>>> | Mob +43 676 62 12 710 | Fax +43.1.402 12 35 - 22
>>>>> 
>>>>> COMPANY INFORMATION
>>>>> | web       : http://www.semantic-web.at/
>>>>> | foaf      : http://company.semantic-web.at/person/juergen_jakobitsch
>>>>> PERSONAL INFORMATION
>>>>> | web       : http://www.turnguard.com
>>>>> | foaf      : http://www.turnguard.com/turnguard
>>>>> | g+        : https://plus.google.com/111233759991616358206/posts
>>>>> | skype     : jakobitsch-punkt
>>>>> | xmlns:tg  = "http://www.turnguard.com/turnguard#"
>>>>> 
>>>> 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
>> 
>> 
>> 
>> 
>> 
> 
> --
> 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.
> -----------------------------
> 

Social Web Architect
http://bblfish.net/

Received on Saturday, 16 February 2013 20:42:05 UTC