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