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