@Jason To be honest, I'm not sure about the other bus implementations. I haven't looked in a while.
On Sat, Sep 24, 2011 at 6:19 PM, Corey Kaylor <[email protected]> wrote: > I might be able to do a hybrid of EventAggregator and regular subscription. > One that simplifies things internally and still provides hooks for > instances. The thing that I'm hung up on is I don't really think that it's > very important for publishing code to know the difference between instance > subscription and regular subscription. Thanks for your comments I'll keep > them in mind before ripping things apart. > > On a side note, I think I can do everything I've described with a new > registration mechanism while keeping all the existing stuff in place and > marking them as deprecated. If it works out it should provide people a > little bit of time to adapt. We'll see when I get a bit further. > > > On Sat, Sep 24, 2011 at 2:47 PM, Matt Burton <[email protected]>wrote: > >> No - what you said makes sense. Doing what I'm doing now is not impossible >> without instance subscription support - I can compensate by building other >> components to stand in and deliver the same results. If removing them would >> make RSB simpler then by all means go for it - I wasn't aware of how >> complicated that feature is. At the end of the day it's saving me from >> having to write extra code in my end to end tests, which is not a big deal. >> >> Thanks, >> Matt >> >> On Sep 23, 2011, at 5:33 PM, Corey Kaylor wrote: >> >> @Matt >> >> The common way that I handle sending messages to a particular instance is >> by having something that handles that concern by itself. One example that we >> have used is something similar to IEventAggregator in Caliburn. In our case >> we have hooks for when instances are created from the container and >> implements Handles<T> and is auto-subscribed with the event aggregator >> (Avoids the need for explicit subscription). >> >> slim example >> >> public void Consume(EventMessage message) >> { >> eventAggregator.Publish(message); >> } >> >> //in another class that might have typically implemented >> OccassionalConsumerOf<T> >> Handle(CustomerMoved message) >> { >> //do something >> } >> >> So the more specific question is... Would it be a big deal in the case of >> a published message on the bus to receive and not have any listeners i.e. >> already created handlers at the destination? >> >> There is a lot of working parts to make the instance subscriptions work >> with little payoff IMO. >> >> Does what I've said make sense, or am I missing something that this type >> of thing wouldn't work for in your case? >> >> On Fri, Sep 23, 2011 at 4:53 PM, Matt Burton <[email protected]>wrote: >> >>> Sounds great, except for getting rid of OccasionalConsumerOf<T> - I >>> use this a great deal in doing end to end tests - very handy. If >>> there's a better way I'd love to know what it is. >>> >>> On Fri, Sep 23, 2011 at 1:14 PM, Corey Kaylor <[email protected]> wrote: >>> > Thinking out loud here and looking to gauge reactions so don't take >>> anything >>> > as concrete. >>> > >>> > After having worked with FubuMVC for some time now and seeing the power >>> that >>> > customizable conventions bring, I've been thinking about how this might >>> > simplify or change things with regard to the .NET service bus >>> > implementations. In addition to thinking about conventions I've had >>> some >>> > ideas or nagging feelings for improvements. Let me know if you have >>> others. >>> > >>> > Some ideas in no particular order. >>> > >>> > Changing heavily the way message endpoints are considered a consumer >>> through >>> > convention, with a set of defaults that still leverages the existing >>> > ConsumerOf<T> >>> > Conventionally describe how sagas are initiated, finished, etc. >>> > Bottles from Fubu to auto wireup endpoints for a given bottle - >>> possibly in >>> > its own appdomain >>> > Conventionally determine routing? >>> > Getting rid of OccasionalConsumerOf<T>, it's ugly, provides little >>> value and >>> > can be handled with event aggregation inside your apps >>> > Conventionally auto-subscribe >>> > Chain of responsibility for consuming message pipline, aka >>> BehaviorChains in >>> > Fubu >>> > Message delivery expiration, if not able to send with timespan, discard >>> (or >>> > insert your convention here) >>> > Endpoints that are considered volatile and will only retry send x times >>> > (might only be possible with rhino queues at the moment) >>> > Conventions for URI's to help with bottles scenario when using rhino >>> queues >>> > and requires more than one listening port >>> > >>> > An example might be at the host level saying for environment 'QA' port >>> > starts with 55 >>> > For the bottle level it might say the port ends with 24 >>> > >>> > Break up the transports into their own packages >>> > In general the transports need to be broken up into different things >>> that >>> > handle smaller responsibility, separated to their own nuget packages >>> > In the same vein the DefaultServiceBus could be broken down and >>> separated as >>> > well, not the core IServiceBus interface, but rather the implementation >>> > Make a common Message type used between transports >>> > >>> > -- >>> > 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. >>> >>> >> >> -- >> 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. >> > > -- 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.
