Yeah - I don't think so either - it's either suffer the pain of the abstraction approach and folks bitching about integrating XYZ IoC container or maintaining a component registration profile for every IoC container out there...
On Mon, Apr 6, 2009 at 10:19 AM, Ayende Rahien <[email protected]> wrote: > that it is not really worth it > > On Mon, Apr 6, 2009 at 7:31 PM, Matt Burton <[email protected]> wrote: >> >> Which, it's not really worth it or the abstraction concept? >> >> On Mon, Apr 6, 2009 at 7:16 AM, Ayende Rahien <[email protected]> wrote: >> > That was my thinking. >> > >> > On Sat, Apr 4, 2009 at 8:47 PM, Matt Burton <[email protected]> >> > wrote: >> >> >> >> That's what I was considering for the implementation of this - >> >> unfortunately it only provides a collection of methods to retrieve >> >> component instances from the container, as it is a service locator. >> >> There would have to be something else that wires up all the correct >> >> components to use in RSB which would be unique per supported container >> >> (Windsor, Autofac, etc...) and to me that seems like an awful lot of >> >> duplication. Per my last email we'd probably be better off looking at >> >> creating an abstraction perhaps over CommonServiceLocator that allowed >> >> for component registration as well. This would be easy to do for the >> >> simple use case of "register this concrete class for this interface" >> >> but when you start dealing with the edge cases, like dealing with >> >> dependencies for the component registrations, it starts getting messy. >> >> NSB has an abstraction like this and I wrestled for quite a bit trying >> >> to implement an Autofac adapter for it. I'll think about it some >> >> more...could be doable, but in the end I don't know how much value it >> >> could really provide. >> >> >> >> On Sat, Apr 4, 2009 at 1:40 AM, Simone Busoli <[email protected]> >> >> wrote: >> >> > >> >> > Have you seen CommonServiceLocator? Would it fit? >> >> > >> >> > 2009/4/4, Matt Burton <[email protected]>: >> >> >> >> >> >> Excellent - great stuff - congrats >> >> >> >> >> >> On Thu, Apr 2, 2009 at 2:46 PM, Ayende Rahien <[email protected]> >> >> >> wrote: >> >> >>> Work is now committed on the trunk. >> >> >>> Fully integrated with RSB now. >> >> >>> Need to do build scripts next. >> >> >>> >> >> >>> On Thu, Apr 2, 2009 at 3:23 PM, Matt Burton <[email protected]> >> >> >>> wrote: >> >> >>>> >> >> >>>> > doesn't really work, think long running apps :-) >> >> >>>> > we have to have this run periodically. >> >> >>>> >> >> >>>> True, some sort of scavenging process. Hmm...well, if the goal is >> >> >>>> to >> >> >>>> keep it in proc you're pretty much stuck with a thread on a timer, >> >> >>>> no? >> >> >>>> You could write an external process to manage it but then you've >> >> >>>> introduced another moving part :( >> >> >>>> >> >> >>>> > In all honestly, I am not sure how feasible this is. I don't >> >> >>>> > mind >> >> >>>> > that, >> >> >>>> > as >> >> >>>> > long as someone else does it :) >> >> >>>> > It is just that I am afraid about the amount of work that is >> >> >>>> > involved. >> >> >>>> > If you will look at RSB now it is just a set of small components >> >> >>>> > that >> >> >>>> > are >> >> >>>> > being brought together by the facilities that bind them. >> >> >>>> >> >> >>>> Right - that's what I figured - basically what we'd be looking at >> >> >>>> is >> >> >>>> writing a custom configuration section that's independent of >> >> >>>> facilities in Castle. I understand that this flies in the face of >> >> >>>> the >> >> >>>> benefits of facilities, but it'll be required in this case. Not >> >> >>>> that >> >> >>>> hard to write, either...just a pain in the butt compared to >> >> >>>> creating >> >> >>>> a >> >> >>>> facility. But do it once and done. Then introduce the >> >> >>>> ServiceLocator >> >> >>>> to do DI. I did notice a number of places in the codebase where >> >> >>>> Windsor / Microkernel is being accessed pretty deep in the bowels, >> >> >>>> but >> >> >>>> hopefully those can be worked around. I can take a look at it >> >> >>>> further >> >> >>>> this weekend to see how feasible all this really is. >> >> >>>> >> >> >>>> On Thu, Apr 2, 2009 at 11:47 AM, Ayende Rahien <[email protected]> >> >> >>>> wrote: >> >> >>>> > inline >> >> >>>> > >> >> >>>> > On Thu, Apr 2, 2009 at 2:25 PM, Matt Burton >> >> >>>> > <[email protected]> >> >> >>>> > wrote: >> >> >>>> >> >> >> >>>> >> LOL - kind of glossed over that part, didn't I? >> >> >>>> >> >> >> >>>> >> Take 2: what jumps out at me first is based on config, a method >> >> >>>> >> that >> >> >>>> >> gets called during dispose and recovery. >> >> >>>> > >> >> >>>> > doesn't really work, think long running apps :-) >> >> >>>> > we have to have this run periodically. >> >> >>>> > >> >> >>>> >> >> >> >>>> >> > Yes, a lot of the complexity goes away completely. It is not >> >> >>>> >> > _just_ >> >> >>>> >> > ITransport, we also need to implement ISubscriptionStorage, >> >> >>>> >> > this >> >> >>>> >> > is >> >> >>>> >> > what >> >> >>>> >> > I >> >> >>>> >> > am doing now. >> >> >>>> >> >> >> >>>> >> Right. And then there's the whole ServiceLocator refactoring >> >> >>>> >> too, >> >> >>>> >> right? Yeah, I know the drill - send you a patch... :) In all >> >> >>>> >> seriousness, would you consider a transition like that? Or at >> >> >>>> >> least >> >> >>>> >> some other abstraction that would allow folks to plug in other >> >> >>>> >> IoC >> >> >>>> >> containers? >> >> >>>> > >> >> >>>> > In all honestly, I am not sure how feasible this is. I don't >> >> >>>> > mind >> >> >>>> > that, >> >> >>>> > as >> >> >>>> > long as someone else does it :) >> >> >>>> > It is just that I am afraid about the amount of work that is >> >> >>>> > involved. >> >> >>>> > If you will look at RSB now it is just a set of small components >> >> >>>> > that >> >> >>>> > are >> >> >>>> > being brought together by the facilities that bind them. >> >> >>>> > >> >> >>>> >> >> >> >>>> >> > Integrating everything is going to be... interesting, shall >> >> >>>> >> > we >> >> >>>> >> > say? >> >> >>>> >> >> >> >>>> >> Indeed - that's why I'm thinking a new implementation that does >> >> >>>> >> away >> >> >>>> >> with the assumptions and restrictions imposed by MSMQ as a >> >> >>>> >> transport >> >> >>>> >> might be warranted. Right - couple that with the PHT for >> >> >>>> >> subscription >> >> >>>> >> storage and saga state storage and you've got a nice little >> >> >>>> >> simple >> >> >>>> >> framework with minimal dependencies. >> >> >>>> >> >> >> >>>> >> On Thu, Apr 2, 2009 at 11:05 AM, Ayende Rahien >> >> >>>> >> <[email protected]> >> >> >>>> >> wrote: >> >> >>>> >> > inline >> >> >>>> >> > >> >> >>>> >> > On Thu, Apr 2, 2009 at 1:54 PM, Matt Burton >> >> >>>> >> > <[email protected]> >> >> >>>> >> > wrote: >> >> >>>> >> >> >> >> >>>> >> >> > Yeah, we probably need both. >> >> >>>> >> >> > The problem is deciding where to implement this. >> >> >>>> >> >> >> >> >>>> >> >> QueueManager configuration DSL? Or even a parameter object >> >> >>>> >> >> passed >> >> >>>> >> >> into >> >> >>>> >> >> the ctor that has Endpoint, Path, >> >> >>>> >> >> MaxNumberOfMessagesToRetain, >> >> >>>> >> >> TimeToRetainMessages as properties - something along those >> >> >>>> >> >> lines? >> >> >>>> >> > >> >> >>>> >> > Um, no. The issue is where to implement the _cleanup_ logic. >> >> >>>> >> > :-) >> >> >>>> >> > >> >> >>>> >> >> >> >> >>>> >> >> > That would still work, actually. >> >> >>>> >> >> > If your service isn't there, the message will be queued at >> >> >>>> >> >> > the >> >> >>>> >> >> > source >> >> >>>> >> >> > until >> >> >>>> >> >> [snip] >> >> >>>> >> >> > So you still get the same (very important) quality. >> >> >>>> >> >> >> >> >>>> >> >> SOLD :) >> >> >>>> >> >> >> >> >>>> >> >> Thinking about a service bus implementation on top of this >> >> >>>> >> >> you >> >> >>>> >> >> could >> >> >>>> >> >> make really a lightweight framework - a lot of the >> >> >>>> >> >> complexity >> >> >>>> >> >> in >> >> >>>> >> >> RSB >> >> >>>> >> >> goes away. (not that there was that much to begin with in >> >> >>>> >> >> comparison >> >> >>>> >> >> to NSB / MT :) Is it really as simple as an ITransport >> >> >>>> >> >> implementation? >> >> >>>> >> >> I guess I'm geared towards small, lightweight, single >> >> >>>> >> >> purpose >> >> >>>> >> >> tools >> >> >>>> >> >> these days (Autofac, AutoMapper, etc...) - a really simple >> >> >>>> >> >> framework >> >> >>>> >> >> built directly on top of RQ seems like a winner to me. (of >> >> >>>> >> >> course >> >> >>>> >> >> using ServiceLocator for IoC so I can use Autofac ;) Just my >> >> >>>> >> >> thoughts... >> >> >>>> >> > >> >> >>>> >> > Yes, a lot of the complexity goes away completely. It is not >> >> >>>> >> > _just_ >> >> >>>> >> > ITransport, we also need to implement ISubscriptionStorage, >> >> >>>> >> > this >> >> >>>> >> > is >> >> >>>> >> > what >> >> >>>> >> > I >> >> >>>> >> > am doing now. >> >> >>>> >> > I am implementing that on the PHT, so that is pretty easy. >> >> >>>> >> > Integrating everything is going to be... interesting, shall >> >> >>>> >> > we >> >> >>>> >> > say? >> >> >>>> >> > > >> >> >>>> >> > >> >> >>>> >> >> >> >>>> >> >> >> >>>> > >> >> >>>> > >> >> >>>> > > >> >> >>>> > >> >> >>>> >> >> >>>> >> >> >>> >> >> >>> >> >> >>> > >> >> >>> >> >> >> >> >> >> > >> >> >> >> >> > >> >> > -- >> >> > Inviato dal mio dispositivo mobile >> >> > >> >> > > >> >> > >> >> >> >> >> > >> > >> > > >> > >> >> > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" 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/rhino-tools-dev?hl=en -~----------~----~----~----~------~----~------~--~---
