I shall make it so :)
> -----Original Message----- > From: Dan Diephouse [mailto:[EMAIL PROTECTED] > Sent: 03 April 2007 17:10 > To: [email protected] > Subject: Re: In Process Dispatch [was Re: [PROPOSAL] Client > and Conduit changes] > > OK, yeah I think so. A couple minor suggestions: > - Pass in a Message to the class instead of an exchange. This > way its clear which message you're selecting a conduit for. > - I am thinking that it might be better to name the > class/method something along the lines of > ConduitSelector.selectConduit - as the Conduit might alright > be instantiated (as in the case of a cluster of Conduits), > but I'll leave that up to you. > > Glad we're making progress now! :) > > Thanks Eoghan, > - Dan > > On 4/3/07, Glynn, Eoghan <[EMAIL PROTECTED]> wrote: > > > > > > > > Hi Dan[D], > > > > Are my responses to your final two questions acceptable to you? > > > > Cheers, > > Eoghan > > > > > -----Original Message----- > > > From: Glynn, Eoghan [mailto:[EMAIL PROTECTED] > > > Sent: 02 April 2007 22:41 > > > To: [email protected] > > > Subject: RE: In Process Dispatch [was Re: [PROPOSAL] Client and > > > Conduit changes] > > > > > > > > > > > > > -----Original Message----- > > > > From: Dan Diephouse [mailto:[EMAIL PROTECTED] > > > > Sent: 02 April 2007 17:41 > > > > To: [email protected] > > > > Subject: Re: In Process Dispatch [was Re: [PROPOSAL] Client and > > > > Conduit changes] > > > > > > > > > > > > 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? > > > > > > > > > Well a flag, being boolean, gives just two options. > > > > > > A pluggable strategy on the other hand would give more > flexibility > > > to take any number of approaches ... use a preexisting > conduit, or > > > create one upfront in ClientImpl.invoke(), or defer creating it > > > until the MessageSenderInterceptor, or retrieve it via some > > > discovery/config mechanism, or select one of a cluster of > endpoints, > > > or any other approach we care to dream up. > > > > > > In addition to the flexibility, the strategy approach has > conceptual > > > benefits - its much easier to digest the logic if > concentrated in a > > > single class as opposed to being buried in code spread across > > > multiple classes. Standard justification for this design pattern. > > > > > > > > > > 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. > > > > > > *Both* are motivations, depending on the use case. > > > > > > In certain scenarios, the late Conduit retrieval would > allow us to > > > avoid needlessly creating a Conduit which would lie > unused if we end > > > up completely by-passing the transport. > > > > > > In other scenarios, the late Conduit retrieval would allow us to > > > ensure the correct Conduit has been selected before initing it. > > > > > > > > > > It seems like it is mostly the later, which is what all > my hubbub > > > > is > > > about. > > > > > > > > > No, its definitely a multiple use-case idea. > > > > > > /Eoghan > > > > > > > > > -- > Dan Diephouse > Envoi Solutions > http://envoisolutions.com | http://netzooid.com/blog >
