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
