Agreed. Charter discussion should also be done in specs@, I suppose.
=nat On Tue, Jun 1, 2010 at 2:25 PM, Dick Hardt <[email protected]> wrote: > Hi Nat, if you want to continue this, let's do it on specs. This list is not > the right one for the technical discussion. > > On 2010-05-31, at 9:52 PM, Nat Sakimura wrote: > >> Here is the XRI canonicalizer for PHP. >> >> <?php >> $openid = $_POST['openid']; >> if(preg_match('/^...@+$!\(]/',$openid)){ >> $url = 'http://xri.net/' . $openid; >> } elseif(preg_match('/^xri:\/\//',$openid) { >> $url = preg_replace('/^xri:\/\//','http://xri.net/',$openid); >> } >> ?> >> >> Rest is the same as normal URL Claimed ID. >> I have never seen somebody use xri://=nat kind of sintax, so the last >> 3 lines can be deleted. >> Then, it is just one liner. >> >> Is it complex? I do not think so. >> >> =nat >> >> On Tue, Jun 1, 2010 at 11:39 AM, Dick Hardt <[email protected]> wrote: >>> >>> On 2010-05-31, at 7:34 PM, Chris Messina wrote: >>> >>>> At the very least, the 2.x series of changes should investigate the >>>> net-net adoption of all of the features of OpenID and prioritize and >>>> de-prioritize accordingly. >>>> >>>> Supporting XRIs have been reported to add complexity to the discovery >>>> code, and further, seem to have little adoption in the mainstream and few >>>> implementations in the wild. I'd be eager to hear specific stats that >>>> contradict that sentiment, but I don't want to hold on to features purely >>>> out of nostalgia. >>>> >>>> This points to yet another reason why I worry about the v.Next naming: if >>>> we can't even cut, cut, cut from the 2.0 spec to create a leaner, simpler >>>> protocol that's easier to implement and support, I have a hard time >>>> imagining how we're going to arrive at a simpler, stream-lined technology >>>> when v.Next sounds like it's chartered to include everything and the >>>> kitchen sink. >>> >>> time will tell :) >>> >>>> >>>> Perhaps along with the MRD/PRD that Brian Kissel wants, we should also >>>> produce a DRD — a developer requirements document — that provides insight >>>> into which features of OpenID have actually been implemented by the most >>>> successful OPs (based on market adoption and usage). That is, in order to >>>> be taken into consideration for this requirements document, you have to >>>> have already deployed a public OpenID Provider and have people using it. >>> >>> Good idea -- but I think you mean implementor not developer here. >>> >>> >>> _______________________________________________ >>> board mailing list >>> [email protected] >>> http://lists.openid.net/mailman/listinfo/openid-board >>> >> >> >> >> -- >> Nat Sakimura (=nat) >> http://www.sakimura.org/en/ >> http://twitter.com/_nat_en >> _______________________________________________ >> board mailing list >> [email protected] >> http://lists.openid.net/mailman/listinfo/openid-board > > _______________________________________________ > board mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-board > -- Nat Sakimura (=nat) http://www.sakimura.org/en/ http://twitter.com/_nat_en _______________________________________________ board mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-board
