Chris, > > Currently, the recommended way is to use the HTTP client as > explained here: > > http://www.restlet.org/tutorial#part02 Then you can check > the call's status > > to see if an error was returned. > > That's useful if you don't know in advance if it's internal > or external....
Right. > > You could also use Call.forward() for internal dispatching > only. Note that > > this logic is being moved to Call.context in beta 18. > > ...but if it's internal this makes more sense. Great. Note that this is broken in SVN, I need to complete some refactoring. > One question about b18. In the changes you have: > > - Removed "requestHeader" and "responseHeader" variables from > CallModel. > > While I see they're now accessed from the ConnectorCall > interface, they > don't seem to be accessible from the Call class or any of its > properties. How can a Restlet (like a filter) get access to the data? I'm investigating some alternative ways to provide this lower-level information. Note that using protocol specific data in "Restlet Applications" will be considered harmful as it breaks the unformity of the Restlet/Call interface. But I do know that having access to this connector-specific information is important for some of you. I'm considering this solution: use some converters that will take a low-level ConnectorCall and transform it into an uniform Call instance. Currently this logic is not clearly separated in the connectors. The idea is to let the developers customize/override those converters in order to play with the connector calls and maybe copy some headers as call's attributes (or the other way around for client connectors). http://restlet.tigris.org/issues/show_bug.cgi?id=145 I'll be interested to know if this would cover your current and planned needs, or if you somehow need access to all the headers during the whole call processing. Thanks, Jerome
