What does the client code looks like? On Sat, Feb 11, 2012 at 6:23 PM, Corey Kaylor <[email protected]> wrote:
> Here is a proof of concept if you want to see what it looks like. > > https://github.com/CoreyKaylor/fubutransportation-spike > > > On Fri, Feb 10, 2012 at 2:27 PM, Corey Kaylor <[email protected]> wrote: > >> A bit of an update on the status of my v3 ideas. >> >> I have successfully made a spike that leverages FubuMVC directly for >> handling messages in RSB and all the boostrapping needs of consumers. >> >> What does this buy us? >> >> 1. All the behavior chain goodness and conventions that Fubu has to offer. >> 2. Modularity via bottles also handled by Fubu boostrapping. >> 3. Leverages subcontainer for lifecycle of a message consumer (no more >> IMessageModule ugliness) >> 4. We can introduce new conventions, if action has a return type, next >> behavior after action would issue a bus.Reply for example >> 5. Possibly reduce or eliminate the requirement for DTC by intercepting >> Send, Publish, etc until all behavior chains have been executed >> successfully then perform the send operations. >> 6. With a little bit of work we would get the Fubu Diagnostics and >> potentially a simple mechanism to expose an admin UI through Fubu running >> on top of Kayak. >> >> What do we lose? >> >> 1. Currently Fubu only has StructureMap support, although it is built >> agnostic >> 2. Likely will have to think through a Fubu + RSB saga story, however the >> existing RSB saga will work and continue to work fine. >> >> Where I plan to focus my efforts... >> >> I want this effort to be more of an adapter rather than a rewrite of RSB >> internals etc. You can opt in if you want to use the adapter, but don't >> have to. >> I want to focus on the separation of ITransport(s) and build a one or two >> more with primary focus on rabbitmq. >> >> Any more thoughts or opinions? >> >> >> On Fri, Jan 6, 2012 at 1:37 PM, Corey Kaylor <[email protected]> wrote: >> >>> I'll keep that in consideration. >>> >>> >>> On Fri, Jan 6, 2012 at 10:33 AM, Jason Meckley >>> <[email protected]>wrote: >>> >>>> that's what I thought :) >>>> >>>> How difficult would this be to implement within RSB itself? I ask >>>> because it seems the more dependencies infrastructure requires, the more >>>> difficult it is to upgrade a system. If the logic is not too complex, the >>>> behavior chain could be built within RSB and no dependency on FUBU would be >>>> required. >>>> >>>> Or would you take advantage of the other FubuCore features as well? In >>>> which case you are already dependent on Fubu. >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Rhino Tools Dev" group. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msg/rhino-tools-dev/-/_7DbSGG5slEJ. >>>> >>>> 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.
