You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oro-dev@jakarta.apache.org by df...@apache.org on 2003/01/03 18:51:12 UTC
cvs commit: jakarta-oro/xdocs status.xml
dfs 2003/01/03 09:51:12
Modified: xdocs status.xml
Log:
Updated status to include short-term goals discussed on oro-dev.
Revision Changes Path
1.7 +52 -3 jakarta-oro/xdocs/status.xml
Index: status.xml
===================================================================
RCS file: /home/cvs/jakarta-oro/xdocs/status.xml,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- status.xml 27 Jun 2002 22:55:08 -0000 1.6
+++ status.xml 3 Jan 2003 17:51:12 -0000 1.7
@@ -15,13 +15,62 @@
Version 2.0.6 is the latest stable release. It currently supports Perl
5.003 regular expressions in the org.apache.oro.text.regex and
org.apache.oro.text.perlpackages. The main development goal is
- to upgrade these packages to support Perl 5.6 regular
+ to upgrade these packages to support Perl 5.8 regular
expressions. The development plan will lay out the path to
achieving this objective and this status page will report the
state of our progress. Our current objective is to settle on a
development plan sometime in the near future.
</p>
-
+ <p>
+ Immediate short-term development goals are summarized in this
+ extract from the oro-dev mailing list:
+ </p>
+<pre>
+ 1. We vote (counting Mark Murphy and Takashi's votes since they've
+ submitted patches that have been applied in one way or another)
+ on releasing v2.0.7 so the latest crop of fixes are available.
+ 2. For you (Bob) to put together some performance unit tests we can
+ run so that we know the changes we're making are having their
+ intended effect.
+ 3. Prioritize this crop of changes. My bias is:
+ 1. Conditional compilation supporting a J2ME target
+ 2. Optional table-based character type lookup
+ 3. Theoretically inlinable input iteration abstraction,
+ using CharSequence for J2SE 1.4
+ 4. Proper case folding.
+ 5. Possibly pool Perl5Repetition objects or something else
+ to reduce impact of memory allocation.
+ This order is based on dependencies that will minimize work as well
+ as complexity. You need 1 before you can do 3 if you're going to
+ support multiple JVMs. You want to do 3 before you do 4 if 4 might
+ affect code that iterates through input; also 3 is easier to implement
+ and less likely to introduce a bug than 4. 5 we don't know if we need
+ to do yet.
+
+Number 4 may not be a quick change to make, but the rest aren't large
+time sinks. If Mark could get us started with just one functionality
+unit test and Bob could get us started with some performance tests,
+I think there will be sufficient grounds to nominate you both as
+committers (Jon and I just have to dig one of the inactive initial
+committers to provide a third vote), which will make it easier for
+each of you to support your respective company's use of jakarta-oro.
+This may just be the thing to kick some life back into development
+and keep my time constraints from being such a bottleneck. As I
+recall, Bob, you also were hoping for group-local modifiers. That's
+something we can tackle if we successfully make it through the above.
+
+As a side note, for bug fixes I'm comfortable with just making the
+fixes as necessary. But for changes that impact the overall API
+or implementation, I think the httpd group's original review code
+first before commit, or at least discuss and agree on the implementation
+beforehand, is the best way to go (and very manageable for this
+project since it's not a lot of code). So, even though I've implicitly
+assigned myself the implementation of some of these changes, I'm not
+going to have at them all without discussion. For example, I'll propose
+a way to reimplement the input traversal to support the use of
+CharSequence and the list can criticize it and counter propose.
+</pre>
+
</section>
</body>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>