Jerome Louvel wrote:
...
Note that this is broken in SVN, I need to complete some refactoring.

('this' being the Call.forward() stuff)

I'll cool my heels for the update, thanks for the warning.

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.

It *is* valuable information, and I don't think we can anticipate every situation where people will need it. Creating a protocol-generic API is useful, but IMO you still need to give people access to what's going on behind the scenes. Even if it's a little messy :-)

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.

So the idea is that a converter I'd write would get invoked after the HTTP ConnectorCall is converted to a Call but still give me access to both? That sounds great! It means I can do what I want with whatever data I want.

One suggestion: you probably want to enable the ability to create a custom Call object and forward it down the chain, so I could do something like this:

  MyCustomCall myCall = new MyCustomCall( call );
  myCall.setSomeProperty( dataFromConnectorCall );
  myCall.setSomeOtherProperty( otherDataFromConnectorCall );
  forward( myCall );

where MyCustomCall is just a subclass of Call that my app knows about so it can access the necessary data without stuffing everything into attributes.

Chris

--
Chris Winters ([EMAIL PROTECTED])
Lead Software Developer
Vocollect Healthcare Systems

CONFIDENTIAL, PRIVILEGED COMMUNICATION: This e-mail is private and intended for the addressee(s) only. It may contain privileged and/or confidential information. If you have received it in error you are not authorized to disseminate it in any manner; please delete it and any copies and reply to the sender that it was misdirected.

Reply via email to