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
