> As soon as we introduce a ConduitSelectionStrategy class having
> getConduit() doesn't imply that a Conduit is always created up front.
Well my whole argument was that the upfront Conduit creation was
unecessary in many cases, but as a compromise I conceded the point that
it remain that way by default, as long as the ConduitSelector mechanism
gave me the flexibility to use alternative strategies.
Of course it would be easy to switch to deferred retrieval by default,
though this would leave me a bit confused as to what exactly we were
arguing about in the first place :)
Maybe we were arguing about different things. My points were that:
a) there needs to be a get/setConduit() on Client
b) Ultimately we should always have a Conduit associated with an exchange
(of course coloc doesn't follow this, but I'll exempt this as a special case
for now )
c) Calling getConduit() should create a conduit if one doesn't exist
We were of course talking about the proposed changes as well. I may have
conflated these issues with the need to always create a conduit if its not
set. For instance I said
"My point is that a user should just be able to do client.getConduit() and
change some transport settings. They shouldn't have to explicitly create the
Conduit though, which is what your proposal does."
I think we were discussing many different things there though. For instance
we could be talking about: getting rid of get/set/Conduit completely, having
getConduit do/not do initilization, and whether or not we should init the
conduit in Client.invoke() if it hasn't been init'd. I was focusing on the
first two things and I think I should've been focusing on the last one now
:-)
So to be clear, as long as a user can call getConduit and have a conduit
init'd for them, I'm ok with whatever. Apologies for any confusion caused
:-\
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
