Chris, > 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 :-)
Absolutely, the only question is where is the best place to give access to this lower-level information. I just think it should be closer to the connectors than to the uniform call. > 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. That's exactly the plan, allow the creation of a custom Call (subclass if necessary) from the ConnectorCall or the other way around for client connectors. Best regards, Jerome
