Hey Krzysztof,

  First, thanks a bunch for your interest in improving WCF integration.

  [1] I think is a nice idea and should be possible with current MK.  Two
approaches would be to use Gauthiers recommendation and preload them in the
Facility or to introduce a SubDepedencyResolver which will resolve it if
present in config section.  The former would register them immediately, the
later on demand.

  [2] Async support is really important. I did read your post and found it
very interesting.  Sorry for not responding.  I got busy and didn't fully
formulate an opinion, but I like the idea.

Once the division of Castle projects get fully organized I would definitely
love any assistance or ideas you have.  In the meantime i'll look into
spiking [1] and reread your proposal for [2].  If you can send me your
current implementation, that would be great.

thanks,
  craig

On Sat, Nov 1, 2008 at 3:28 AM, Krzysztof Koźmic <[EMAIL PROTECTED]
> wrote:

>  Hi,
>
> Since Hammlet asked to move that discussion out of the leaders topic, here
> we go.
> For features I have two big ones so far, I'd like to see. The thing with
> them is, however, that both require changes to other projects.
> - First, The ability to resolve wcf proxies/ServiceHosts without having to
> register those explicitly with Windsor, if they are registered with WCF.
> For example, on the client, when I have defined my proxy in the config file
> like this:
>
>         <client>
>             <endpoint 
> address="http://localhost:27197/UsingWindsor.svc";<http://localhost:27197/UsingWindsor.svc>
>                       binding="basicHttpBinding"
>
> contract="Castle.Facilities.WcfIntegration.Demo.UsingWindsorSvc.IAmUsingWindsor"
>                       name="WSHttpBinding_IAmUsingWindsor">
>             </endpoint>
>         </client>
> Why can't I do simply this [1]:
>
>             var windsorContainer = new WindsorContainer()
>                 .AddFacility<WcfFacility>();
>             var wcfProxy = windsorContainer.Resolve<IAmUsingWindsor>(
> "WSHttpBinding_IAmUsingWindsor");
>
> I know that I can use information from the config file with this [2]:
>             windsorContainer.Register(Component.For<IAmUsingWindsor>()
>                 .Named("usingWindsor")
>                 .ActAs(new DefaultClientModel()
>                 {
>                     Endpoint = WcfEndpoint
>                         .FromConfiguration("WSHttpBinding_IAmUsingWindsor")
>                 }));
>
> But it feels like it's just repeating information  I already have in the
> config file. [1] Feels much more natural.
> Now, I know that this would be impossible with current implementation of
> MK, because I won't allow me to resolve component that were not registered
> explicitly.
> That's why I want to ask - Why not discuss about changing it. My
> proposition is not to go quite as far as Unity, that will try to resolve any
> type you ask of it.
> I'm thinking about something in the middle.
> Let's call it MetaComponentProvider for discussion's sake. The way I see
> it, would go like this:
> - You (WcfIntegrationFacility) register your MetaComponentResolver
> (WcfConfigurationResolver) with the IKernel.
> - When User asks for component (IAmUsingWindsor with name
> "WSHttpBinding_IAmUsingWindsor") MK first tries to resolve it, if it's
> explicitly registered
> - If it's not MK asks MetaResolver if given those information (type and
> name) it can provide the component.
> - MetaResolver based on the information checks the config file and then, if
> there is such service, it get's resolved just as any other component.
>
> I know that it would require deep changes in the MK and it's just a
> proposition so don't jump on me for that ;)
>
> Second, The ability for calling AsyncPattern methods on a non-svcutil
> proxy. I wrote about it some time ago (
> http://groups.google.com/group/castle-project-devel/browse_thread/thread/9250110e258ccdcd),
> but the thread got widely ignored.
> I already have some of the implementation working. I still need to write
> runtime generation of async version of the service interface and more
> complete version of IAsyncClient implementation.
>
> Thoughts?
>
> Krzysztof
>
> Craig Neuwirt pisze:
>
> Nothing planned as of yet.  Did you have anything in mind?
>
> On Thu, Oct 30, 2008 at 5:00 PM, Krzysztof Koźmic <
> [EMAIL PROTECTED]> wrote:
>
>> While we're at it:
>> is there a roadmap, especially for WCFIntegration? Any clear direction the
>> project will evolve?
>>
>> Krzysztof
>>
>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Castle Project Development List" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/castle-project-devel?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to