Hi Rob, Thanks for perfectly summarizing the situation. I like your proposition of exposing a new property. I just propose to name it "originalRef" instead as it is already relative to the Request class, implicitely meaning "originally requested reference" :-) Best regards, Jerome _____
De : Rob Heittman [mailto:[EMAIL PROTECTED] Envoyé : vendredi 16 mai 2008 23:46 À : [email protected] Objet : Re: Disabling the TunnelService I feel like part of the debate results from the contract of Request.getResourceRef() being unclear. There seem to be at least two differences of opinion in common circulation: 1) - getResourceRef() is returning the reference of the resource *as originally requested* by the client. OR 2) - getResourceRef() is returning the reference of the resource *after processing* by filters and services in the Restlet plumbing. In addition, because we use RIAP a lot, we also have a 3), the reference of the resource as seen from the external client which triggered some chain of internal requests. This is probably a boundary case. I have seen fairly experienced Restlet users try to use getResourceRef().getBaseRef() and such to try to get at one of these meanings when it seems another of the meanings is being used. In point of fact, the first two cases are just ambiguous. My suggestion would be to canonize meaning 2) for getResourceRef() -- as this seems to be what it is now anyway -- and to expose a new getRequestedRef() which returns the original client-requested reference in a way that is fairly difficult to mutate by accident. Those of us who ABSOLUTELY NEVER want a mutated reference in a certain context can then be assured of getting it. - R
