You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by Henry Zongaro <zo...@ca.ibm.com> on 2010/01/04 17:54:15 UTC
Re: XalanJ Future - Part 2
Hi, Adam.
Adam Jenkins <ad...@yahoo.com.au> wrote on 12/10/2009
11:47:57 AM:
> And when I get back I'll be forking the XalanJ codebase over to
> dev.java.net.
I recently added a comment on your enhancement request [1] suggesting a
way we might move forward - in particular, I wrote, "the right way forward
might be to create a branch and add your contribution there. Then people
can extract and build the code, play with it, make further contributions
to address the concerns. After that, we could fold it back onto the main
trunk. Let me know how you feel about that suggestion."
I haven't seen a response to that proposal, and I haven't seen anything in
dev.java.net to indicate that you'd forked the Xalan-J code, so I thought
I'd ping you to get your thoughts.
Thanks,
Henry
[1] http://tinyurl.com/yf9esym
------------------------------------------------------------------
Henry Zongaro
XML Transformation & Query Development
IBM Canada Lab T/L 313-6044; Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com
Re: XalanJ Future - Part 2
Posted by Adam Jenkins <ad...@yahoo.com.au>.
Hi Henry,
Thanks for the post. I'm currently doing a bunch of code diving to see how big the impact of implementing your requirements are going to be. The way Xalan does variable assignment is quite different to what I'm used to seeing in interpretter code, with all variables being preprocessed and assigned an index, which is then used to reference the variable. At this stage I need a greater understanding of the code to decide whether a branch is even possible, or whether a complete fork is necessary.
For example, the current variable management system makes it quite difficult (for me with my limited knowledge at least) to extend it in any meaningful way....I'm not just talking about the extensions that I wanted to make, but also things like custom variable resolvers, which is a common concept in other interpretter systems. I am pretty confident (again, more investigation being done this week and next week) that if I was to try to meet your requirements for the extension element functionality, my modifications to the variable handling code would be quite large, so probably wouldn't make it into trunk anyway because of regression testing requirements.
But again, still code diving to gain a full understanding of the impact of this and future changes. At the moment, I seem to be in a bit of a "damned if you do, damned if you don't" scenario, with a low impact change not robust enough to make it to trunk, and a robust change too high impact to make it into trunk. The more I look at it, the more a fork feels like the only option available.
So what I'm trying to figure out at the moment is how large my changes are going to be, and from that, how likely is it that any branch I were to create would ever make it back into trunk. Because if it turns out that, for example, the entire variable handling code need a rewrite (not something I want, I hate rewrites) then it's probably best if it spawns to be a seperate offering as the chance of that modification going back into trunk are probably tiny.
Anyway, I'll keep the list posted as things progress.
Cheers
Adam
--- On Tue, 5/1/10, Henry Zongaro <zo...@ca.ibm.com> wrote:
> From: Henry Zongaro <zo...@ca.ibm.com>
> Subject: Re: XalanJ Future - Part 2
> To: "Adam Jenkins" <ad...@yahoo.com.au>
> Cc: xalan-dev@xml.apache.org, xalan-j-users@xml.apache.org
> Received: Tuesday, 5 January, 2010, 3:54 AM
>
>
> Hi, Adam.
>
>
>
> Adam Jenkins
> <ad...@yahoo.com.au>
> wrote on 12/10/2009 11:47:57 AM:
>
> > And when I get back I'll be forking the XalanJ
> codebase over to
>
> > dev.java.net.
>
>
>
> I recently added a comment
> on your enhancement
> request [1] suggesting a way we might move forward - in
> particular, I wrote,
> "the right way forward might be to create a branch and
> add your contribution
> there. Then people can extract and build the code, play
> with it, make further
> contributions to address the concerns. After that, we could
> fold it back
> onto the main trunk. Let me know how you feel about that
> suggestion."
>
>
>
> I haven't seen a
> response to that proposal,
> and I haven't seen anything in dev.java.net to indicate
> that you'd forked
> the Xalan-J code, so I thought I'd ping you to get your
> thoughts.
>
>
>
> Thanks,
>
>
>
> Henry
>
> [1] http://tinyurl.com/yf9esym
>
> ------------------------------------------------------------------
>
> Henry Zongaro
>
> XML Transformation & Query Development
>
> IBM Canada Lab T/L 313-6044; Phone +1 905
> 413-6044
>
> mailto:zongaro@ca.ibm.com
>
>
__________________________________________________________________________________
See what's on at the movies in your area. Find out now: http://au.movies.yahoo.com/session-times/
Re: XalanJ Future - Part 2
Posted by Adam Jenkins <ad...@yahoo.com.au>.
Hi Henry,
Thanks for the post. I'm currently doing a bunch of code diving to see how big the impact of implementing your requirements are going to be. The way Xalan does variable assignment is quite different to what I'm used to seeing in interpretter code, with all variables being preprocessed and assigned an index, which is then used to reference the variable. At this stage I need a greater understanding of the code to decide whether a branch is even possible, or whether a complete fork is necessary.
For example, the current variable management system makes it quite difficult (for me with my limited knowledge at least) to extend it in any meaningful way....I'm not just talking about the extensions that I wanted to make, but also things like custom variable resolvers, which is a common concept in other interpretter systems. I am pretty confident (again, more investigation being done this week and next week) that if I was to try to meet your requirements for the extension element functionality, my modifications to the variable handling code would be quite large, so probably wouldn't make it into trunk anyway because of regression testing requirements.
But again, still code diving to gain a full understanding of the impact of this and future changes. At the moment, I seem to be in a bit of a "damned if you do, damned if you don't" scenario, with a low impact change not robust enough to make it to trunk, and a robust change too high impact to make it into trunk. The more I look at it, the more a fork feels like the only option available.
So what I'm trying to figure out at the moment is how large my changes are going to be, and from that, how likely is it that any branch I were to create would ever make it back into trunk. Because if it turns out that, for example, the entire variable handling code need a rewrite (not something I want, I hate rewrites) then it's probably best if it spawns to be a seperate offering as the chance of that modification going back into trunk are probably tiny.
Anyway, I'll keep the list posted as things progress.
Cheers
Adam
--- On Tue, 5/1/10, Henry Zongaro <zo...@ca.ibm.com> wrote:
> From: Henry Zongaro <zo...@ca.ibm.com>
> Subject: Re: XalanJ Future - Part 2
> To: "Adam Jenkins" <ad...@yahoo.com.au>
> Cc: xalan-dev@xml.apache.org, xalan-j-users@xml.apache.org
> Received: Tuesday, 5 January, 2010, 3:54 AM
>
>
> Hi, Adam.
>
>
>
> Adam Jenkins
> <ad...@yahoo.com.au>
> wrote on 12/10/2009 11:47:57 AM:
>
> > And when I get back I'll be forking the XalanJ
> codebase over to
>
> > dev.java.net.
>
>
>
> I recently added a comment
> on your enhancement
> request [1] suggesting a way we might move forward - in
> particular, I wrote,
> "the right way forward might be to create a branch and
> add your contribution
> there. Then people can extract and build the code, play
> with it, make further
> contributions to address the concerns. After that, we could
> fold it back
> onto the main trunk. Let me know how you feel about that
> suggestion."
>
>
>
> I haven't seen a
> response to that proposal,
> and I haven't seen anything in dev.java.net to indicate
> that you'd forked
> the Xalan-J code, so I thought I'd ping you to get your
> thoughts.
>
>
>
> Thanks,
>
>
>
> Henry
>
> [1] http://tinyurl.com/yf9esym
>
> ------------------------------------------------------------------
>
> Henry Zongaro
>
> XML Transformation & Query Development
>
> IBM Canada Lab T/L 313-6044; Phone +1 905
> 413-6044
>
> mailto:zongaro@ca.ibm.com
>
>
__________________________________________________________________________________
See what's on at the movies in your area. Find out now: http://au.movies.yahoo.com/session-times/
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org