We don't have a contrib project. The problem that I have with this is that I do no want to have to support complex stuff.
On Sat, Sep 26, 2009 at 8:39 AM, Steve Wagner <[email protected]> wrote: > > Whats about providing the code for the hashtable in a Contrib or > Extensions subdirectory? > > Ayende Rahien schrieb: > > Right now I am working on the ESB parts of the port, and I am thinking > hard > > again about what should and shouldn't be in there.On the one hand, one of > > the major reasons that I created RSB is that I wanted to make something > that > > is developer friendly and easy to get started. > > On the other hand, there are some things where we do want to provide > > extensibility and customization for the users. > > For the most part, I think we managed to do that by using the container > in > > some clever ways, but with the DHT saga storage I think I really messed > it > > up. > > It is complex, both to set it up and to make use of it and to understand > how > > it works. > > I have tentatively removed it from the project. > > I would like to provide a saga storage that is easy to use and fit the > bill > > for most of the operations that you need, without bringing undue burden > for > > the administrator or developer. > > > > Last week I had several discussions with Udi about that, and he pointed > out > > that the most commonly used and easiest to reason about is a locked saga > > state. That is, during the execution of a transaction, the state of the > saga > > is locked. A common example would be using a DB to handle that while > using > > serializable transactions. > > > > I still want to enable the "let us just use this" mode, and I still want > to > > avoid dependencies on infrastructure that isn't xcopy deployable. > > We can support this easily if we will utilize only the PHT. But that will > > work for local mode only. We can make use of the DHT, but then we need to > > provide a solution for farm wide locking. A lot of the design behind the > DHT > > is based on always on system, because I have a requirement to keep the > > system going while nodes are coming and going. Locking is... interesting > in > > this scenario. I would love to hear options about that. > > > > Or, we could just provide a simple DB saga state and let the DB handle > that > > and clustering to handle fail over. > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
