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 -~----------~----~----~----~------~----~------~--~---
