[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Link processing rules and linked XRDs (was: Delegation Terminology / Linked XRD)
I forgot to add my four reasons for preferring the link priority processing model: 1) It does not require an XRD processor to automatically fetch all linked XRDs (and all XRDs linked to those XRDs, and so on recursively) before it can complete discovery. 2) It eliminates the complexity of trying to determine priority order across multiple XRDs. With the link priority processing model, the scope of priority order is always a single XRD. 3) It is simple to understand and apply. 4) You can achieve something very similar to the "flat" model (where all linked XRDs are treated equally) just by careful arrangement of link priority. =Drummond > -----Original Message----- > From: Drummond Reed [mailto:drummond.reed@cordance.net] > Sent: Wednesday, July 08, 2009 10:37 PM > To: 'Will Norris'; 'XRI TC' > Subject: [xri] Link processing rules and linked XRDs (was: Delegation > Terminology / Linked XRD) > > I feel pretty strongly about the advantages of the priority-based link > processing rule, i.e., that an XRD processor should process the links in > XRD1 in priority order until it either finds the related resource it is > looking for or exhausts all links in XRD1. > > This means that if, following priority order of links in XRD1, the > processor > reaches a linked XRD (call it XRD2), the processor should then halt > further > processing of links in XRD1, fetch XRD2, and continues recursively, i.e., > processes XRD2 links in priority order until the related resource is > discovered or the links are exhausted. > > This model includes two other rules: > > 1) The backtracking rule, i.e., if the links in XRD2 are exhausted with no > success, the processor returns to the rest of the links in XRD1 and > continues in priority order until either: a) the related resource is > found, > b) another XRD (XRD3) is followed, or c) the links are exhausted and the > process terminates. This rule is applied recursively (to XRD2, XRD3, etc.) > > 2) The equal priority rule, which is that anytime two or more links have > the > same priority, the XRD processor MUST choose among them randomly. This > gives > you a simple form of round-robin capability. > > I won't be on the call tomorrow, but I hope this helps with the > discussion. > > =Drummond > > > -----Original Message----- > > From: Will Norris [mailto:will@willnorris.com] > > Sent: Wednesday, July 08, 2009 3:10 PM > > To: XRI TC > > Subject: Re: [xri] Delegation Terminology / Linked XRD > > > > Forgot to reply to this earlier in the week, but we do need to wrap up > > this discussion and decide how to move forward... > > > > I agree that this is an absolutely valid model, and was actually the > > first one I envisioned. One thing to take into consideration when > > flattening these XRDs is what to do with the Link priorities. What if > > XRD1 has two related resources, an OpenID provider with priority of 5, > > and another XRD with priority of 10. That linked XRD, XRD2, also > > lists an OpenID provider with a priority of 1. So which OpenID > > provider should be used first? The one with priority of 1, because it > > has the lowest priority value? But the linked XRD had a priority of > > 10... is that taken into consideration when determining the "effective > > priority" of resources linked from that XRD? There are a couple of > > different ways to answer it, but my point is that you will probably > > want to be explicit in how applications should handle this to ensure > > consistent behavior. > > > > The second problem with this approach is that you end up fetching > > every XRD for the resource every time, even if the highest priority > > <Link> ends up being in the first document. I don't anticipate people > > going too crazy with linked XRDs, but it is certainly a practical > > deployment issue we should consider. > > > > With the proposed approach of sorting by priority first, and then > > fetching linked XRDs as necessary, it solves both the question of how > > to handle "effective priority" as well as "just in time fetching" of > > linked XRDs. It certainly changes how we need to word the priority > > attribute section, since it assumes you're sorting a pre-filtered set > > of elements. > > > > -will > > > > > > On Jul 4, 2009, at 10:46 AM, Eran Hammer-Lahav wrote: > > > > > My point is that if you draw a graph of the resource and all its > > > links from the various sources and XRDs, it looks like you should > > > flatten the content of XRDs, not search them in order... > > > > > > EHL > > > > > >> -----Original Message----- > > >> From: Will Norris [mailto:will@willnorris.com] > > >> Sent: Friday, July 03, 2009 11:25 PM > > >> To: XRI TC > > >> Subject: Re: [xri] Delegation Terminology / Linked XRD > > >> > > >> > > >> On Jul 3, 2009, at 5:11 PM, Eran Hammer-Lahav wrote: > > >> > > >>>> Well there is a precedence. Even though a XRD-linked XRD shares > > >>>> the > > >>>> semantics as one linked from an HTTP header, we can't ignore the > > >> fact > > >>>> that <Link> elements do in fact have a priority. I remember that > > >>>> LRDD > > >>>> specifically stated that determining which one of multiple > > >>>> describedby > > >>>> links should be used was application specific. And that seems to > > >>>> make > > >>>> sense because there is no good deterministic way to order them. We > > >>>> can order <Link> elements though, so it makes sense to respect > > >>>> their > > >>>> order. > > >>> > > >>> I agree that Link priority must take precedence but that's the easy > > >>> case. What happens when all priorities are equal. > > >> > > >> > > >> If a linked XRD is really just another linked resource, then the spec > > >> instructs consuming applications to choose randomly. > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe from this mail list, you must leave the OASIS TC that > > >> generates this mail. Follow this link to all your TCs in OASIS at: > > >> https://www.oasis-open.org/apps/org/workgroup/portal/ > > >> my_workgroups.php > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe from this mail list, you must leave the OASIS TC that > > > generates this mail. Follow this link to all your TCs in OASIS at: > > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe from this mail list, you must leave the OASIS TC that > > generates this mail. Follow this link to all your TCs in OASIS at: > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]