I'm trying to understand what goals can't be met. Oliver is implying that none of it is possible, but I don't understand how it would be impossible to have transactional collections as the web page mentions.
I agree that I would like to understand what the challenges are before closing it down. Ralph On Mar 6, 2010, at 2:51 PM, Henri Yandell wrote: > I think the next step would be to raise the issue on the dev list - > retiring Transaction because xyz. Then if no one has any bright ideas > or helps you have any bright ideas then we can go ahead and move it > onto the retirement side. > > It's a pretty strong message to say "This is just not implementable. " > so I imagine we'd want to bash the thoughts around a bit to make sure > they hold up. > > Hen > > On Fri, Mar 5, 2010 at 1:41 PM, Oliver Zeigermann > <[email protected]> wrote: >> I thought about it for a while and I really think it is true. Of >> course you could change what is on the tin, but then it would no >> longer be of major interest. >> >> Thus, except anyone else wants to bring it further, the project is dead. >> >> What would be the steps for its funeral (feels bad as this would be >> the second Apache project funeral I am involved in)? >> >> - Oliver >> >> 2010/3/5 Henri Yandell <[email protected]>: >>> That would be dead then :) >>> >>> If it's not possible - I think we should retire the library asap with >>> such a statement. Do not use - it's not able to do what it says on the >>> tin. >>> >>> Is there any more conversation we should have before determining that >>> a) it's misleading and b) there shouldn't be a 1.3 or 2.0 release with >>> the improved if not great functionality? >>> >>> Hen >>> >>> On Fri, Mar 5, 2010 at 2:01 AM, Oliver Zeigermann >>> <[email protected]> wrote: >>>> Folks! >>>> >>>> What Henri says is completely right. >>>> >>>> The project has been abandoned by me as I lost faith in one of its >>>> goal - ACID properties (especially atomicity) on any file system. From >>>> my (and others) point of view it can not be achieved by *any* >>>> implementation. So if you are asking whether there is another >>>> implementation that is more suitable, my answer is "there can't be >>>> any". >>>> >>>> Certain parts of the 2.0 code are quite reasonable, though, especially >>>> the locking and deadlock detection part. That's why I have not been >>>> determined what to do with the project. Certainly 2.0 is better than >>>> 1.x by any means, but I still think it should not be released as its >>>> promises can not be kept. >>>> >>>> Any thoughts? >>>> >>>> - Oliver >>>> >>>> 2010/3/5 Henri Yandell <[email protected]>: >>>>> The current version is 1.2 (released in 2007). >>>>> >>>>> 1.3-SNAPSHOT is then the subsequent version in development, but it >>>>> looks as though it was quickly renamed to 2.0. >>>>> >>>>> 2.0 currently has 6 of 9 issues resolved, the most recent being >>>>> reported and applied in Sept 2009, and 2 of the open issues were >>>>> opened a month ago. >>>>> >>>>> So I wouldn't call it dead - there just hasn't been much to do. Your >>>>> email does raise the question of whether 2.0 should be released or >>>>> not. I've cc'd Oliver who has been doing most of the work. >>>>> >>>>> Hen >>>>> >>>>> On Tue, Feb 9, 2010 at 10:07 PM, John Ericksen <[email protected]> >>>>> wrote: >>>>>> Hello, >>>>>> >>>>>> I came across the file transaction capabilities in commons-transaction >>>>>> today >>>>>> which was exactly what I was looking for. To my disapointment, however, >>>>>> it >>>>>> looks like there hasn't been an update to the project for over 2 years. >>>>>> The >>>>>> home page says the current version is a SNAPSHOT and from my search of >>>>>> the >>>>>> mailing list, it looks like 2.0 is upcoming (in 2007?). >>>>>> >>>>>> My question is, is the commons-transaction project abandoned, is there a >>>>>> better library out there for transactional file system operations? >>>>>> >>>>>> Thanks for your reply. >>>>>> >>>>>> John >>>>>> >>>>> >>>> >>> >> > > --------------------------------------------------------------------- > 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]
