Speaking as a non-user of Digester, it would seem that as long as a new version can process the same XML configs, and retains the ability to plug in/adapt extensions written against v2, breakage of other APIs (which should be minimal in such a library) isn't terribly important. Again, this is spoken from a position of ignorance, so feel free to tell me how and why I'm wrong.
$0.02, Matt On Jan 24, 2011, at 4:01 AM, Simone Tripodi wrote: > That's very good Rahul, > being yourself also a Digester users, it should be easier for me > having you to give a guideline :) > Have a nice day! > Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > > > On Mon, Jan 24, 2011 at 4:08 AM, Rahul Akolkar <rahul.akol...@gmail.com> > wrote: >> On Sun, Jan 23, 2011 at 9:47 PM, Simone Tripodi >> <simonetrip...@apache.org> wrote: >>> Hi Rahul! :) >>> good point, I think that this is yet another good reason to work on >>> sandbox before, I'll try to stay close as much as possible to the >>> current Digester concept, my idea/purpose/intensions are providing a >>> new Digester and not replacing it. >> <snip/> >> >> Great, lets put ourselves in the shoes of existing digester users >> (indeed, I am one). >> >> If that doesn't sound like fun, the rewrite can always be proposed as >> a new component :-) >> >> -Rahul >> >> >>> Of course, suggestions/participation/feedbacks/guidelines are always >>> accepted, many thanks in advance!!! >>> Simo >>> >>> http://people.apache.org/~simonetripodi/ >>> http://www.99soft.org/ >>> >>> >>> >>> On Mon, Jan 24, 2011 at 3:25 AM, Rahul Akolkar <rahul.akol...@gmail.com> >>> wrote: >>>> On Sun, Jan 23, 2011 at 9:11 PM, Simone Tripodi >>>> <simonetrip...@apache.org> wrote: >>>>> Hi Rahul!!! :) >>>>> thanks for your feedbacks!!! this time I would like to experiment in >>>>> the sandbox an almost complete rewrite of Digester, simplifying the >>>>> actual design centralizing the configuration - and loosing >>>>> retro-compatibility. Moreover I would like doing a strong code >>>>> polishing, removing deprecated APIs at first stage. >>>>> >>>> <snip/> >>>> >>>> If we're losing compatibility in the core component APIs due to a >>>> major rewrite, it may be better as a new component rather than the >>>> next major release. >>>> >>>> -Rahul >>>> >>>> >>>>> The idea can, of course, be ported also on the current Digester >>>>> implementation, so once the sandbox will be completed we could apply >>>>> the new feature also on 2.X and at the same time think about a >>>>> possible 3.X. >>>>> WDYT? >>>>> Have a nice day, all the best, >>>>> Simo >>>>> >>>>> http://people.apache.org/~simonetripodi/ >>>>> http://www.99soft.org/ >>>>> >>>>> >>>>> >>>>> On Sun, Jan 23, 2011 at 11:08 PM, Rahul Akolkar <rahul.akol...@gmail.com> >>>>> wrote: >>>>>> On Sun, Jan 23, 2011 at 1:23 PM, Simone Tripodi >>>>>> <simonetrip...@apache.org> wrote: >>>>>>> Hi all guys, >>>>>>> I would like to propose a new sandbox to experiment a fresh, >>>>>>> different, new set of Digester APIs that strongly uses a DSL for rules >>>>>>> configuration. >>>>>>> As described in the original proposal[1], the idea comes from a James >>>>>>> Carman's comment on an old Digester issue, so his >>>>>>> help/guidance/mentoring would be more than appreciated. >>>>>>> Please cast your vote, if there are no objections I would like to >>>>>>> start this work in the sandbox and try to promote as TLP with your >>>>>>> help/mentoring/involvement. >>>>>> <snip/> >>>>>> >>>>>> This would be in addition to the existing digester APIs? I think we >>>>>> want to be compatible so don't know if it makes sense to remove/change >>>>>> existing APIs. >>>>>> >>>>>> The sandbox is always open for experimentation, no objections there. >>>>>> >>>>>> -Rahul >>>>>> >>>>>> >>>>>>> I really hope this could be point of your interest that makes you >>>>>>> curious enough to participate! >>>>>>> Have a nice day, all the best, >>>>>>> Simo >>>>>>> >>>>>>> [1] http://markmail.org/message/5ry2lmfkpxkrqwh6 >>>>>>> >>>>>>> http://people.apache.org/~simonetripodi/ >>>>>>> http://www.99soft.org/ >>>>>>> >>>>>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
