- From: Jürgen Jakobitsch <j.jakobitsch@semantic-web.at>
- Date: Sat, 16 Feb 2013 21:07:04 +0100
- To: Henry Story <henry.story@bblfish.net>
- Cc: Kingsley Idehen <kidehen@openlinksw.com>, "public-webid@w3.org Group" <public-webid@w3.org>
henry, you continue to tune your examples in favour of your preference, that is not exactly scientific, hence my example. 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/ > -- | 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#"
Received on Saturday, 16 February 2013 20:07:28 UTC