[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Backtracking
John, In thinking about this, I’m not sure
backtracking needs make for “unclean code”. It seems to me that, as
the ED07 flowcharts reflect, SEP selection is just as necessary during the authority
resolution stage as after it, and thus implementations need to maintain their state
in the XRDS “tree” no matter whether they are following Refs at the
XRD level or the Service level. (The same thing applies to Redirects but Refs
are more complex so in this message we’ll just discuss Refs). For example, say you want to resolve an
XRI for an OpenID SEP, and by following Refs during both authority resolution and
SEP selection, you ended out with the following XRDS tree: XRDS ref=”@a*b*c” XRD
for *a XRD
for *b XRDS
ref=”@x*y” XRD
for *x XRD
for *y XRDS
ref=”@d*e*f” XRD
for *d XRD
for *e XRD
for *f /XRDS /XRDS XRD
for *c ;end
of authority resolution XRDS
ref=”@m*n” XRD
for *m XRD
for *n XRDS
ref=”@p*q*r” XRD
for *p XRD
for *q XRD
for *r ;end of SEP
selection /XRDS /XRDS /XRDS It seems to me that to keep our
backtracking rules simple and clean, an implementation must keep track that
when it hits the first Ref and starts the nested XRDS for @x*y, and again when
it hits the next Ref and starts the next nested XRDS for @d*e*f. Then when it
finishes authority resolution, it knows where it needs to “back up to”
to place the final XRD for *c. Then the same thing starts all over again once authority
resolution is complete but the resolver needs to follow the Refs it encounters in
the final stage of SEP selection. From that perspective, doing SEP selection
during authority resolution is no different than doing SEP selection after authority
resolution is over – the only difference is that in the first stage you
have a pre-defined SEP selection parameters, while in the second stage you have
input-defined SEP selection parameters. But otherwise the two traversal paths and
requirements are the same. So it would seem simpler and more consistent to keep
the traversal/backtracking rules the same. (Anything we can do to keep Redirect
and Ref processing simpler and more consistent gets my vote since it’s
complicated enough as it is.) I too would very much like to get the
other implementor’s (Victor, Kermit, Markus, Wil, that’s you ;-)
view on this ASAP – any change here would be much bigger than any of the
rest of the changes to ED06, all of which are pretty minor at this point. =Drummond From: John Bradley
[mailto:jbradley@mac.com] My question is more what constitutes a failure when the ref is at the
XRD level. While the original query may be performing SEP selection, is it our
intent for the authority resolution step to maintain the state of SEP
selection? The current proposal has the Authority resolution stage tracking what
service is being asked for, and failing the Authority resolution of the ref if
the service is not found so it can try the next ref. My only concern is that this makes for unclean code. =ve7jtb PS I am not touching the ref must be followed question I have already
done that once today. On 25-Oct-07, at 6:00 PM, Chasen, Les wrote:
I am not sure
when this change came about. REFs should only be followed in the search of a
service whether at the xrd level or service level. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]