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