Hi Alex,
Thanks for sharing the Atomojo usage details.
The TunnelService has been turned on since 1.0 and nobody complained (yet)
about the default query parameters ("method", "charset", "encoding",
"language" and "media"). If needed they can be renamed by the user. Also
note that when they are matched, those query parameters are removed from the
"resourceRef" property.
So the current behavior regarding extensions was not really a fundamental
change :-), but it's visibility/impact was greater than for query parameters
and gave you this feeling. It definitely indicates that there is a lack of
documentation regarding the semantics of the "resourceRef" property.
Currently, when the extensions are touched, the TunnelService puts the
original reference in a "org.restlet.TunnelService.originalRef" attribute of
the request. But this is not very easy to use.
So, I propose to replace this attribute by a more explicit
"Request.originalRef" property and clearer Javadocs regarding
"Request.resourceRef" whit cross-refs with "originalRef".
Would that work for you?
Best regards,
Jerome
-----Message d'origine-----
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Alex
Milowski
Envoyé : lundi 19 mai 2008 22:19
À : [email protected]
Objet : Re: Disabling the TunnelService
On Mon, May 19, 2008 at 1:31 AM, Jerome Louvel <[EMAIL PROTECTED]> wrote:
>
> Hi Alex,
>
> Like Thierry, I have just checked the code again and in trunk the
extensions
> tunnel feature is now off by default.
>
> The idea behind this feature is to have a very simple way for a user to
> specify, for any resource hosted within an application, which
representation
> he wants. The standard way is to use the "Accept" header (hard with
browsers
> and not very intuitive), the other way is to use the "?media=xml" query
> parameter which is processed by the TunnelService by default and converted
> into the equivalent "Accept" header info (the query parameter is then
> removed from the 'resourceRef' to make this feature transparent to the
> application resources).
I understand this is a good feature but many applications may find intruding
on the resource reference a problem. That is, what if the "media" query
parameter is already used.
Now, if you want such a feature... having to just make a single call
to turn it on is probably really useful.
> Now with the extensions tunneling, the user can just append ".xml" to the
> last segment and have an effect similar to using an "Accept: text/xml"
> header, with no change to the application logic. I would be interested to
> understand why/how it breaks your URI processing logic, but my feeling is
> that in 90% of cases, it will be a very convenient feature. BTW, we
already
> support something similar for the Directory class.
In atomojo, the extension is a choice made by the user using the atom
publishing protocol. They send a "slug" header to control the actual
file name. As such, the extension could be ".foo" or ".myrandomxmldocument"
for text/xml and not ".xml". That means that I need to honor the original
requested file name in the last segment and attempt to find it in the
storage. I have all the requested information for formulating the
response and setting the media type in an database external to the actual
storage vehicle.
In the case of the tunnel service, what doesn't make sense to me
is that it seems like the extension information just disappeared. It wasn't
that it was placed in another facet of the Reference instance and I had
to get at it using getExtensions(). It just completely vanished. As such,
I could not reconstruct the original last segment.
> Also, if you want to have a common configuration policy across all your
> applications (for example to disable all services and associated filters),
> then I suggest that you use a BaseApplication class extending
> o.r.Application.
As a policy, I turn off the TunnelService explicitly in all my applications
because what tasks it performs do not help me.
> I do feel your pain regarding the unexpected changes to your URIs and
logic,
> and I apologize for the time lost in figuring out what happened. I think
> that Rob's proposition to add a "requestedRef" property and to clarify
> "resourceRef" Javadocs is a good way to clarify the actual intent.
No need to apologize. I was very surprised and frustrated with what seemed
like a very fundamental change.
In this case, I do rely upon getResourceRef() related processing. I do
want getRemainingPart() to give me the matching portion minus the
path that go to my application via routing. It is just that the tunnel
service
gets inserted automatically that was surprising to me.
--Alex Milowski
