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