Providing an abstraction of some sort like IPublishMessages would be preferable over losing the behavior altogether for this one transport.
On Wed, Nov 23, 2011 at 6:44 PM, John Duddy <[email protected]> wrote: > Having the transports in their own assemblies would be great. It took me > awhile to figure out the touch points from the two existing transports. > > So, would it be an unacceptable change in the metaphor to do away with the > subscription tracking for this one transport type, since subscribers and > publishers can be running at non-overlapping times? > > > On Wed, Nov 23, 2011 at 5:38 PM, Corey Kaylor <[email protected]> wrote: > >> You would need to implement and register an ITransport. >> >> There are no assumptions for "local reliable queues", just no >> implementations otherwise. >> >> If you invoke bus.Publish instead of bus.Notify the bus will throw when >> there are no subscribers. >> >> For subscriptions you would need to implement and register an >> ISubscriptionStorage. >> >> Nothing else you've said sounds off or incorrect. >> >> In V3 I plan to split out transports other than the MSMQ transport >> (possibly subscription storage) into their own assemblies. I won't begin >> work on this until January timeframe though. Until then you may find some >> friction with the # of assemblies and dependencies that may not seem >> justified. >> >> On Wed, Nov 23, 2011 at 5:24 PM, John Duddy <[email protected]> wrote: >> >>> I'd like to add support for Amazon's SQS. >>> >>> I found a previous thread discussing this, which stated that Rhino >>> assumed "local reliable queues". I also noticed some notes in the >>> documentation about different instances subscribing to each other, and >>> throwing errors if a message was sent with no subscribers (although I >>> may have misread this). >>> >>> I'd like to break those assumptions, and I'd like some feedback as to >>> if that's a Really Bad Idea (tm). >>> >>> First, I'd like to throw an exception if a message can't be sent by >>> the underlying transport. It looks to me that is what already occurs >>> if there is a failure in MSMQ (like disk full error), so I am thinking >>> this might be OK. >>> >>> Second, since SQS allows queries, I'd like to move the subscription >>> tracking responsibilities out of Rhino for SQS and have each >>> subscription drive a query loop that will pick up messages that match >>> the type signature. Since producers & consupers can come up and go >>> down independently, and since SQS will store messages for 4 days, this >>> seemed like a nice way to scale. >>> >>> I'm only a few days into this effort, so I'd really appreciate any >>> tips you could offer. >>> >>> Thanks! >>> >>> -- >>> 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. >>> >>> >> -- >> 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. >> > > > > -- > John Duddy > [email protected] > > -- > 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. > -- 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.
