Re: Web Identity and Discovery - WebID 1.0

hi,

reading this whole thread is a lecture in FUD [1] and a clear
indicator of the community's willingness to commit suicide.

1. have performance issues ever been tested in another than "i have a
feeling that"-way?
2. please do not confuse the members of this community with the rest of
the world. there are enough people who have absolutely no problem
deploying a 303 redirect (i'm willing to show, if there are troubles).
3. can someone point me to an application architecture in connection
with webID besides robots that would make such a lack performance really
feelable for the enduser.
4. my experience with the word "performance issue" is that it is the
last wall of defence when someone doesn't want to code something. it is
a 1st class buzzword that aims at constructing feelings.
5. please open up http://plus.google.com in firefox open firebug's
console and check how many requests are made just to show the page.
6. do the same with facebook
7. even tiny twitter takes three requests just to show the startpage.
8. after 5-7 think again about the "performance issue" of that one
redirect.

wkr j


[1] http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt

On Wed, 2013-02-06 at 16:10 +0100, Henry Story wrote:
> On 6 Feb 2013, at 15:39, Kingsley Idehen <kidehen@openlinksw.com> wrote:
> 
> > On 2/6/13 6:39 AM, Andrei Sambra wrote:
> >> As promised, I have updated the spec according to the latest poll results. I've also cleaned it up a little, mainly fixing inconsistencies with some terms.
> >> 
> >> I would like to ask everyone to take a look and see if everything is ok before we move to WebID-TLS.
> >> 
> >> Here is the link to the latest version: https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/identity-respec.html
> >> 
> >> Best,
> >> Andrei
> > Why do you still have this warning:
> > 
> > "Implementers are highly encouraged to use hash URIs for the WebID HTTP URI. Even though 303 redirects have been used in the past, experience has shown that they can be difficult to deploy and can have an impact on performance. However WebID Verifiers must not fail when dereferencing hashless URIs, though they may flag them as potentially impacting on performance."
> > 
> > You don't need that piece of confusion. The examples can be hashed based and just leave it at that.
> > 
> > I thought this matter was completely closed based on the vote i.e.:
> > 
> > 1. A WebID is a HTTP URI
> > 2. Use hash based HTTP URIs in all examples.
> 
> yes, but it is still true that there is a cost for the client and for deployment of non hash based URIs, since they require 1 extra dereferencing: ie. one more connection on the network. The speed of light being limited, this is a cost. 
> 
> I would change the "can have impact on performance" to "have impact on performance".
> 
> Perhaps "highly encouraged" can be reduced to "encouraged". In any case we need some reason 
> to explain in the spec why the examples are in terms of hash uris.
> 
> Henry
> 
> > 
> > 
> > -- 
> > 
> > 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
> > 
> > 
> > 
> > 
> > 
> 
> 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 Thursday, 7 February 2013 07:26:44 UTC