I think that it is creating _transactional_ queues by default. The reason that it exists in this manner is quite simple. It reduce the number of things that you need to do to use RSB. You don't have to go and explicitly create the queue. It just happens. One less thing to do.
I see no problem with moving the responsibility to Rhino Service Bus Facility, though. On Fri, Jan 23, 2009 at 4:46 AM, Mike Nichols <[email protected]>wrote: > > I just committed some fixes to the FlatQueue implementation in RSB > 1. A #subscriptions queue is required as a sibling queue > 2. Initialization of queues in Transport is based on the strategy > > One question though: We are currently only creating nontransactional > queues if they don't already exist. SHould we add a config option on > the facility to specify IsTransactional ? Or should the creation of a > queue even be in the Transport...it seems like a SRP violation to have > it in there and should just throw if it can't new() the queue. > Queue setup like creation, purging, and so on seems like it should be > the burden of the app code, not RSB. A simple static class could > provide these utilities ala PrepareQueues in sample. > > mike > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
