OK, no objections from other transaction guys, so I understand the scope proposal is accpeted :)
Oliver On Tue, 16 Nov 2004 23:51:13 +0100, Oliver Zeigermann <[EMAIL PROTECTED]> wrote: > OK, I added the scope proposal to > > http://jakarta.apache.org/commons/sandbox/transaction/ > > I have to admit it is somehow inspired by the scope of the concurrent > package and also by Roberts sketch ;) > > Any objections from the other transaction guys? > > Thanks for pointing in that direction Robert, I appreciate it! > > Oliver > > On Tue, 16 Nov 2004 22:30:19 +0000, robert burrell donkin > > > <[EMAIL PROTECTED]> wrote: > > > > > > > > On 16 Nov 2004, at 22:03, Oliver Zeigermann wrote: > > > > > I think your request is very reasonable. However, this really is an > > > integrated component. Both the file system and the maps rely on the > > > locks. Compare this to e.g. > > > > > > http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/ > > > intro.html > > > > > > where you have a similar structure for more general concurrent Java > > > programming. You have locks that are used by the channels and the > > > collections and some more general purpuse helpers. You would not split > > > this to more than one package, would you? > > > > we've found in the commons that tight, focussed components have done > > best :) > > > > thinking about scope before promotion and writing it down saves > > arguments later. (it's also part of the charter.) > > > > > Now, the transaction component aims at the same thing as the > > > concurrent package, but is specific to transactions. > > > > that makes sense. > > > > so (for example) like doug lea's original, transaction (probably) aims > > to be lightweight with minimal dependencies, and provides well tested, > > rigourous solutions for the most common use transactional use cases. (i > > have no doubt that you'll probably come up with something a lot > > better...) that way, in years to come when oddballs propose some > > heavyweight solution with big dependencies for an obscure problem, > > you'll be able to points them straight to your scope, saving weeks of > > argument :) > > > > > You are very right and this really should be made explicite, thus I > > > will add this as a scope to the index page of the transaction > > > component ASAP. > > > > > > May a presume that this changes your vote to +1? > > > > come up with a good scope, discuss (as necessary) with the transaction > > community then commit and i'll cast a new vote :) > > > > (you'll thank me in the long run for insisting that you don't rush ;) > > > > - robert > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
