Hi Lars, I think you will be happy to know that I've found a simpler solution. Now, the HTTP server|client connectors systematically pass the list of request|response headers as an attribute in the call's attributes map.
You can even specify headers to be added to the response|request. Only non-standard headers are allowed in this case to prevent conflicts with normal connectors' behavior. I've created a new example illustrating reading arbitrary headers and setting an extension one: http://restlet.tigris.org/source/browse/restlet/trunk/plugins/internal/com.n oelios.restlet.example/src/com/noelios/restlet/example/misc/HeadersTest.java ?rev=947&view=markup Let me know if you still have concerns. Best regards, Jerome > -----Message d'origine----- > De : Jerome Louvel [mailto:[EMAIL PROTECTED] > Envoyé : vendredi 15 septembre 2006 19:51 > À : [email protected] > Objet : RE: b19 - Call converters > > > Hi Lars, > > Thanks for detailing your concerns, that really helped me to > reach your > point of view. Now you got me puzzled :-) > > > Yes. But I cannot give my restlet to another developer and it just > > works. She has to change her implementation just because I want to > > read headers. > > As long as I work in my microcosmos everything works fine > but nobody > > outside my microcosmos can use my Restlet and my utilities without > > changing the implementation. > > Ok, the portability is not achieved by simply using call converters, > especially because the converters are specific to NRE's > implementation. > > > I understand your concerns and everything you write is > right. I liked > > the releases until b18, because releases < b18 provided the uniform > > call but if an user really really wants / has to escape from the > > uniform Call outside to the underlying technology it was possible. > > I see, but providing access to the lower-level call (if it > exists!) also > creates a portability issue. If you want true portability, > then you need to > move those lower-level classes into the Restlet API and force the > implementation to use those lower-level calls. That forbids > the possibility > of an optimized HTTP server connector that would directly generate an > uniform Call instance. Also, if we move the HttpCall class, > we also have to > provide equivalent for all potential protocols to ensure that > new connectors > can be built for them and use like the HTTP ones... > > > I get (and set) for example something like this (source: [TMIP]): > > GET /internet/web//browser/bn`s HTTP/1.1 > > Host: server1.farm.example.org > > X-TMIP-Accept-Scope: uc, en, de, * > > Accepts: text/xml > > > > But how do I get "X-TMIP-Accept-Scope" *without* modifying > > the uniform call (side effects)? > > Are my requirement too specific? ;) > > Ok, we need an intermediary solution. My idea is this: consider the > Application (including a set of Restlets and connector > requirements) as the > only unit of portability. Then allow some parameters to be > set for each > connector, independently of other applications within the > same container. > For example, two applications should be able to listen to > HTTP on the same > port, while reading different headers. > > So, the idea would be to set parameters like this (HTTP server): > "getRequestHeader" -> "acceptScope: X-TMIP-Accept-Scope" > "setResponseHeader" -> "foo: X-TMIP-Foo" > > As a result of the first command, the connector would place the > "X-TMIP-Accept-Scope" header into the "acceptScope" attribute. > > For a HTTP client connector: > "setRequestHeader" -> "acceptScope: X-TMIP-Accept-Scope" > "getResponseHeader" -> "foo: X-TMIP-Foo" > > The advantage of this approach is that we don't have to bring any > protocol-specific class into the Restlet API and also we > don't impose any > implementation constraint on the connectors, for example they > might use > lower-level connector calls or directly uniform calls while > respecting the > same contract (which would be specified in the Restlet API Javadocs). > > Would that work better? I'm currently working on the > application support and > hope to have something testable soon. > > Best regards, > Jerome
