Re: [xri] RE: #next: alternate to #replace

[Breno de Medeiros <breno@google.com>]

Argh, what is going on with my editor? Please ignore the previous
email, it included text I had deleted.

On Fri, Sep 18, 2009 at 8:49 AM, Breno de Medeiros <breno@google.com> wrote:
> What I really had in mind is that discovery would return a list of
> XRDs, and there would be a specific concrete answers to these two
> types of questions by processing the list:
>
> node = discover(resource, rel type)
>
>
> Actually, no I can't give the example, because as someone who has
> interacted with XRD discovery extensively as an OpenID developer, I
> suspect that every existing use case is for either:
>
> node = discover(resource, rel type)
> list of Types = discoverType(resource)
>
> However, I realize now that this is undesirable because it requires
> pre-fetching all XRDs to answer the first type of question.
>
> Unfortunately Brian Eaton lost a battle early on in this process to
> avoid writing a discovery spec that gives meaning to the operation
>
> xrd = discover(resource)
>
> I think that is the source of all complication :) XRDs are treated as
> first-class objects, when efficiency and simplicity considerations
> indicate that they should be treated as partial representations of a
> discovery process, with this spec only defining how to answer each of
> the types of question above.
>
> How come we didn't concentrate on this crucial issue early on? At this
> point, I think we should stick with #replace. In additional to the
> complexity, it has profound consequences from the perspective of
> efficiency also.
>
>
> On Thu, Sep 17, 2009 at 11:01 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
>> Can you give me an example of a linked XRD to show how this will work? Walk me through the steps of finding all the <Type>s and picking a <link>.
>>
>> EHL
>>
>>> -----Original Message-----
>>> From: Breno de Medeiros [mailto:breno@google.com]
>>> Sent: Thursday, September 17, 2009 10:57 PM
>>> To: Eran Hammer-Lahav
>>> Cc: XRI TC
>>> Subject: Re: [xri] RE: #next: alternate to #replace
>>>
>>> On Thu, Sep 17, 2009 at 10:42 PM, Eran Hammer-Lahav
>>> <eran@hueniverse.com> wrote:
>>> >
>>> >
>>> >> -----Original Message-----
>>> >> From: Breno de Medeiros [mailto:breno@google.com]
>>> >> Sent: Thursday, September 17, 2009 9:58 PM
>>> >> To: Eran Hammer-Lahav
>>> >> Cc: XRI TC
>>> >> Subject: Re: [xri] RE: #next: alternate to #replace
>>> >>
>>> >> Okay, I see the metaphor that you are describing, but XML parsers
>>> are
>>> >> not written as compilers.
>>> >
>>> > Obviously. But if you look past the XML structure and just think of
>>> the data items inside an XRD, it is a linear list. As it is currently
>>> defined, if you grab each linked XRD, strip its <XRD> envelope and
>>> <Subject> (after trust validation it has no other meaning here), you
>>> can just insert the rest into the linking XRD.
>>> >
>>> >> My point is that since we have potentially many XRD choices for a
>>> >> resource (depending on the start point), would it be a deal breaker
>>> to
>>> >> have discovery potentially generate multiple independent XRDs prior
>>> to
>>> >> final selection procedure? I guess the answer is no, as long as
>>> after
>>> >> the selection procedure the result is unambiguous.
>>> >>
>>> >> The processing rule for <Link> could make the order of preference
>>> >> fixed so that one always picks the first XRD that matches a
>>> desirable
>>> >> 'rel' type. E.g.: depth-first-search.
>>> >
>>> > It could but that is up to the protocol to decide. Consider the
>>> OpenID discussions about the order of precedence across links from
>>> HTML, HTTP, and host-meta. You don't just collapse them all into a
>>> single list. The context of where you find the link to the XRD matters.
>>> >
>>> >> For <Link>-independent <Type> discovery, only the root XRD would be
>>> >> used.
>>> >
>>> > My question is, how do you envision this to work with the very basic
>>> use case of one resource redirecting consumers elsewhere for its XRD?
>>> We started this with an HTTP 301 but because we can't sign HTTP
>>> redirections, we moved it into an XRD. If <Type>s don't cross XRD
>>> document lines, these resources will have no <Type>s.
>>>
>>> I did not mean that they would have no <Type>. I meant that the <Type>
>>> is indicated in a single XRD.
>>>
>>>
>>> >
>>> > EHL
>>> >
>>> >
>>>
>>>
>>>
>>> --
>>> --Breno
>>>
>>> +1 (650) 214-1007 desk
>>> +1 (408) 212-0135 (Grand Central)
>>> MTV-41-3 : 383-A
>>> PST (GMT-8) / PDT(GMT-7)
>>
>
>
>
> --
> --Breno
>
> +1 (650) 214-1007 desk
> +1 (408) 212-0135 (Grand Central)
> MTV-41-3 : 383-A
> PST (GMT-8) / PDT(GMT-7)
>



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)