Just because you see this as the way to solve your use case doesn't
necessarily mean it is the way we should support. I'm certainly want to
support this scenario and I'm sure we will come to some agreement about how
to best support it. BUT, there are other goals as well though - like
simplicity and coherency. If we've already got mechanisms for this type of
thing, why go inventing others?

Do you agree that it is possible to delay the addition of Binding
interceptors to the chain inside the Client? Would it maybe be better to
delay this decision until later in the chain? This would avoid the
introduction of a flag mechanism.

If so, then why don't we just allow users to select a different Binding up
to POST_LOGICAL phase? For instance, the ObjectBinding interceptors could be
added if that person wanted to do a local invocation. They could also select
a new Conduit up to this point as well. If the user doesn't select a
different binding or conduit, then we'll just use the default ones.

In addition to allowing your use case of allowing the interceptor to
control the binding, this makes the URI based approach much easier as well.



One last addition, because I didn't address getting the part about getting
the Conduit up front.

Let me sidestep first to your questions of why your proposal is getting so
much scrutiny - well there are conflated discussions of whether or not
Conduits are needed for in process dispatching and whether or not we should
adopt my proposed client changes. If we say that a Conduit is optional for
invocations, then that has big ramifications in those areas.

If all we're trying to decide on is creating a way to avoid initializing a
Conduit by default, then I only have two questions before adopting your
approach:
- Why should we have a ConduitInitiatorStrategy as opposed to just setting a
flag on the Conduit? If someone sets the flag to false the
MessageSenderInterceptor can always fall back and init a Conduit later using
the EndpointInfo.
- Is your only objection that we may not always need the specific Conduit
that is inited? And that this may consume resources? Or is the motivation
for this approach that you just don't want to use a Conduit at all. It seems
like it is mostly the later, which is what all my hubbub is about.

- Dan

--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Reply via email to