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