RE: Jakarta Overview
I have to disagree! Speaking as a /user/ it is really hard to find projects on Jakarta, and how the various projects relate to each other. I have spent many weeks doing this and still haven't even scraped the iceberg. Which I think is a shame. Some clear exposition would really help. I have heard on this list that the Jakarta project is developer centric, and the site is hard to penetrate if you are not a Jakarta developer. I am sure this is not by design, but that is my perception as well. Any suggestion that helps improve this situation such as Philipp's I would hope has serious consideration - even if it presents new challenges that need to be resolved. As to deciding such things as how to assess the maturity of the project, how about taking measures such as: a) polls/votes of users b) number of downloads c) release number I'm sure there are other possibilities... Chris. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Ceki Gulcu Sent: 20 March 2002 10:27 To: Jakarta General List Subject: Re: Jakarta Overview Isn't the overview document trying to substitute itself for the documentation that is already in subprojects (or should be)? The cornerstone of the Jakarta and Apache Software Foundation in general is that management delegates responsibility for a given subproject to each subproject, intervening as little as possible. Your introduction also raises further worries. Jakarta does not need more publicity. Everybody knows Jakarta. What is needed is improving the quality of each *subproject*. Marketing gimmicks are not helpful and just waste precious time. More importantly, who is to decide what project has what maturity? I find the overview document a little too interventionist, perhaps less in content than in sprit. Until these concerns are addressed, here is my -1. At 16:36 18.03.2002 -0800, you wrote: Greetings! I have been following some of the recent discussions on this mailing list about possible directions for the Jakarta project. I would like to offer the following observation: To have code and projects coming out of Jakarta being more widely adopted, developers first need to be aware of them, then they have to be able to judge whether a Jakarta project is suitable for the developers' needs. I believe that the Jakarta website could do more to make its products easily accessible. It is often not easy to tell what a project is actually about, what the project's scope is, how its functionality is achieved, or how mature and usable the existing code base is. Evaluating an of-the-shelf component usually is an iterative process: In a first step one tries to determine the overall purpose of the component, and whether it is suitable for one's purpose at all. In later steps, one may consider how the component works, and what distinguishes it from comparable/competing products. The Jakarta subprojects support this evaluation and decision process to various degrees. The one that I am most familiar with (Velocity) is exceptional in this regard (mere coincidence?). But some (sub-)projects force the potential user to study the Javadoc to find out which problem the project attempts to solve, which is probably unacceptable for many visitors. I think it would be helpful for everyone (in particular in light of the desire to see Jakarta code being more widely adopted in outside projects) to try to improve the information offered here, and to support visitors in their evaluation and decision process as much as possible. After this introduction... Here is what I have done: I have scoured the entire Jakarta website and compiled information not only on each project, but also on each of the subprojects (such as those in the Commons, or those that are part of Avalon or Turbine), which are not immediately visible when visiting the Jakarta homepage. For each project, I have included a short, one-paragraph description (often taken from the projects webpage), but I also tried to give a sense of the maturity and the activity of the project. For anybody wanting to use (as opposed to develop) Jakarta code in their own projects, this information will play a significant part in their final decision. (I report the version number as proxy for the maturity and the extend of the News section of each project as proxy for its activity.) I hope that by providing the information not only about the top level project, but also about all the individual subprojects in one location, a visitor to the site will have an easier time assessing purpose and scope of each of the projects. I would hope that this can be extended in the future to include the following: - a concise abstract, stating what the project is about and what purpose it serves (the foundation for which I hope to provide here, based on what many projects already offer on their individual homepages) - a description how the project works, possibly by walking the visitor through a Hello, world example
RE: jakarta-tomcat-4.0.3.exe
This question will be better answered on the [EMAIL PROTECTED] list. Randy -Original Message- From: Jian Hu [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 19, 2002 4:15 PM To: [EMAIL PROTECTED] Subject: jakarta-tomcat-4.0.3.exe Hi, I am a loyal user of Apache Tomcat. I am very interested in executible program jakarta-tomcat-4.0.3.exe. I try to make setting up process clear. It seems that following your instruction could not make it work well. But the .exe did function well for me. Can I have the souce code of the program ? It would be highly appreciated if you could send it to me via email. Thanks a lot. Jian -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jakarta Overview
Perhaps you could become a Jakarta developer by altering the provided overview so that it is both useful to users and acceptable to the developers of the projects it covers. I should say a subjective (mature/immature/good/bad) information might be useful, but probably is more the area of a Jakarta fan-site ;-) then the Jakarta site itself. Furthermore, just a personal opinion, Documentation is an area I truly want to help improve at Jakarta as a whole. But, one thing I've noticed is that it is much easier to contribute documentation at the project level and work your way up then vice versa. I like the overview myself, its a clear and gives folks an easier way to find what they need. I yet understand the concerns about keeping it up to date and the likes. My suggestion is though is too fold. General tends to give new contributers who read the literature about community and the likes a trial by incident, a series of -1 no I don't like it! and depend upon the contributer to climb the mountain. Rough for a first timer. Perhaps trying to be a bit more positive and saying good but have you considered instead of the more traditional approach. ;-) Secondly, to the contributer of said documentation and future contributers. While end to end documentation is seriously lacking, I suggest contributing to the in developing Jakarta Manual and furthermore the lower level project documentation first. Try not to include too much subjective information (cause for debate) and don't take it personally ;-) or anything anywhere at anytime too seriously. (air raids and the likes excluded) -Andy On Wed, 2002-03-20 at 05:35, Chris Pheby wrote: I have to disagree! Speaking as a /user/ it is really hard to find projects on Jakarta, and how the various projects relate to each other. I have spent many weeks doing this and still haven't even scraped the iceberg. Which I think is a shame. Some clear exposition would really help. I have heard on this list that the Jakarta project is developer centric, and the site is hard to penetrate if you are not a Jakarta developer. I am sure this is not by design, but that is my perception as well. Any suggestion that helps improve this situation such as Philipp's I would hope has serious consideration - even if it presents new challenges that need to be resolved. As to deciding such things as how to assess the maturity of the project, how about taking measures such as: a) polls/votes of users b) number of downloads c) release number I'm sure there are other possibilities... Chris. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Ceki Gulcu Sent: 20 March 2002 10:27 To: Jakarta General List Subject: Re: Jakarta Overview Isn't the overview document trying to substitute itself for the documentation that is already in subprojects (or should be)? The cornerstone of the Jakarta and Apache Software Foundation in general is that management delegates responsibility for a given subproject to each subproject, intervening as little as possible. Your introduction also raises further worries. Jakarta does not need more publicity. Everybody knows Jakarta. What is needed is improving the quality of each *subproject*. Marketing gimmicks are not helpful and just waste precious time. More importantly, who is to decide what project has what maturity? I find the overview document a little too interventionist, perhaps less in content than in sprit. Until these concerns are addressed, here is my -1. At 16:36 18.03.2002 -0800, you wrote: Greetings! I have been following some of the recent discussions on this mailing list about possible directions for the Jakarta project. I would like to offer the following observation: To have code and projects coming out of Jakarta being more widely adopted, developers first need to be aware of them, then they have to be able to judge whether a Jakarta project is suitable for the developers' needs. I believe that the Jakarta website could do more to make its products easily accessible. It is often not easy to tell what a project is actually about, what the project's scope is, how its functionality is achieved, or how mature and usable the existing code base is. Evaluating an of-the-shelf component usually is an iterative process: In a first step one tries to determine the overall purpose of the component, and whether it is suitable for one's purpose at all. In later steps, one may consider how the component works, and what distinguishes it from comparable/competing products. The Jakarta subprojects support this evaluation and decision process to various degrees. The one that I am most familiar with (Velocity) is exceptional in this regard (mere coincidence?). But some (sub-)projects force the potential user to study the Javadoc to find out which problem the project attempts to solve, which is probably unacceptable for many
Re: The Complete Server Platform?
Daniel Rall wrote: Also, would you point me to a reference on how memory management is handled? It uses the Boehm collector. For full details see here: http://www.hpl.hp.com/personal/Hans_Boehm/gc/ It is a conservative collector that can also implement garbage collection for C and C++, though gcc doesn't yet take advantage of this. It's a fairly decent collector, I think, that implements most of the obvious optimisations such as generations, exploitation of the MMU, etc. Its conservative nature is both an upside and a downside. On the downside, a small amount of storage may not get reclaimed -- though unlike leaky C programs, this amount tends not to increase with time. On the upside, there is less overhead because the collector doesn't have to distinguish between pointers and other types. -- Pete -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jakarta Overview
Jakarta is developer-centric because developers are the ones who volunteer to do the work. They need working products to use with their paying jobs, and find that sharing the development load works better than going it alone. We don't get many marketing volunteers because there is very little payback. More marketing generates more users, but that doesn't always translate into more development or better products. Sometimes more users can actually hurt development, since user support distracts developers from developing. (Only so many cycles in a day.) I do a lot of work on product documentation myself, mostly becuase I have a mind like a sieve, and need it for my own reference. But for most developers and users, there is less of a payback, since once they know the product they don't feel the need to document it for their own use. Jakarta is here to build products. If someone wants to market those products, that's great. If volunteers want to provide commit-ready documentation, like Phillip did, I'll fulfill my responsibility as a committer, and post it. But the problem now is, who's going to maintain it over the long run? If the developers want to, that's great, but if they don't, well, how the other committers spend their volunteer hours is up to them. So, sure, some clear exposition about Jakarta would help a lot of people. If someone has an itch for more documentation, they should create it and share it with the group in a ready-to-commit format, as Phillip did. Though, I'm sure anyone ready to do the work doesn't need someone else to suggest the idea. Jakarta cannot be anything by design; it can only be what the volunteers make it. -- Ted Husted, Husted dot Com, Fairport NY US -- Developing Java Web Applications with Struts -- Web: http://husted.com/struts Chris Pheby wrote: I have to disagree! Speaking as a /user/ it is really hard to find projects on Jakarta, and how the various projects relate to each other. I have spent many weeks doing this and still haven't even scraped the iceberg. Which I think is a shame. Some clear exposition would really help. I have heard on this list that the Jakarta project is developer centric, and the site is hard to penetrate if you are not a Jakarta developer. I am sure this is not by design, but that is my perception as well. Any suggestion that helps improve this situation such as Philipp's I would hope has serious consideration - even if it presents new challenges that need to be resolved. As to deciding such things as how to assess the maturity of the project, how about taking measures such as: a) polls/votes of users b) number of downloads c) release number I'm sure there are other possibilities... Chris. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jakarta Overview
Well said Andrew. Re. Chris's point, I think we'll be hard pressed to reach consensus on what a project maturity means, let alone how to measure it. If I were building this document (and if I remember correctly, I built this document: http://jakarta.apache.org/commons/components.html, which is rather similiar in some respects), I'd stick to factual information--brief description, release dates/numbers, etc. and let the facts speak for themselves. -Original Message- From: Andrew C. Oliver To: Jakarta General List Sent: 3/20/2002 6:27 AM Subject: RE: Jakarta Overview Perhaps you could become a Jakarta developer by altering the provided overview so that it is both useful to users and acceptable to the developers of the projects it covers. I should say a subjective (mature/immature/good/bad) information might be useful, but probably is more the area of a Jakarta fan-site ;-) then the Jakarta site itself. Furthermore, just a personal opinion, Documentation is an area I truly want to help improve at Jakarta as a whole. But, one thing I've noticed is that it is much easier to contribute documentation at the project level and work your way up then vice versa. I like the overview myself, its a clear and gives folks an easier way to find what they need. I yet understand the concerns about keeping it up to date and the likes. My suggestion is though is too fold. General tends to give new contributers who read the literature about community and the likes a trial by incident, a series of -1 no I don't like it! and depend upon the contributer to climb the mountain. Rough for a first timer. Perhaps trying to be a bit more positive and saying good but have you considered instead of the more traditional approach. ;-) Secondly, to the contributer of said documentation and future contributers. While end to end documentation is seriously lacking, I suggest contributing to the in developing Jakarta Manual and furthermore the lower level project documentation first. Try not to include too much subjective information (cause for debate) and don't take it personally ;-) or anything anywhere at anytime too seriously. (air raids and the likes excluded) -Andy On Wed, 2002-03-20 at 05:35, Chris Pheby wrote: I have to disagree! Speaking as a /user/ it is really hard to find projects on Jakarta, and how the various projects relate to each other. I have spent many weeks doing this and still haven't even scraped the iceberg. Which I think is a shame. Some clear exposition would really help. I have heard on this list that the Jakarta project is developer centric, and the site is hard to penetrate if you are not a Jakarta developer. I am sure this is not by design, but that is my perception as well. Any suggestion that helps improve this situation such as Philipp's I would hope has serious consideration - even if it presents new challenges that need to be resolved. As to deciding such things as how to assess the maturity of the project, how about taking measures such as: a) polls/votes of users b) number of downloads c) release number I'm sure there are other possibilities... Chris. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Ceki Gulcu Sent: 20 March 2002 10:27 To: Jakarta General List Subject: Re: Jakarta Overview Isn't the overview document trying to substitute itself for the documentation that is already in subprojects (or should be)? The cornerstone of the Jakarta and Apache Software Foundation in general is that management delegates responsibility for a given subproject to each subproject, intervening as little as possible. Your introduction also raises further worries. Jakarta does not need more publicity. Everybody knows Jakarta. What is needed is improving the quality of each *subproject*. Marketing gimmicks are not helpful and just waste precious time. More importantly, who is to decide what project has what maturity? I find the overview document a little too interventionist, perhaps less in content than in sprit. Until these concerns are addressed, here is my -1. At 16:36 18.03.2002 -0800, you wrote: snip snip
Re: The Complete Server Platform?
On Tue, 19 Mar 2002, Jon Scott Stevens wrote: One other question: Is there a valuable performance enhancement to compiling to native code with gcj? Right now - no, I couldn't notice any significant difference while running tomcat. It is as fast as IBM JIT ( and faster than hotspot ). However it start much faster, and get to the peak performance sooner ( since all optimizations are already done ). Another nice thing is that all the java code is actually compiled to .so - and fully interoperable with C++ ( for C you need to deal with the mangling ). That's very similar with C# and .net languages, and it's not bad at all. GCJ can be a very good answer to .NET, with a bit of work it may allow the same language independence ( GCC already does a lot in this direction ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: LICENSE in .jar files
Sorry for my tangent - it's clear that on legal matters, I should just
get the heck outta Dodge and let someone with more patience work on it.
8-{
I've forwarded a link (with threading) to your (Conor's) message to the
xml PMC so they should be aware of this licensing issue with JAXP and xml-commons.
=
- Shane
eof aka=mailto:[EMAIL PROTECTED];
.sig=Du sublime au ridicule il n'y a qu'un pas. /
__
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards®
http://movies.yahoo.com/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: LICENSE in .jar files
So could a non-tainted person through black box testing produce their own JAXP clone? -Andy On Wed, 2002-03-20 at 19:55, Conor MacNeill wrote: From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Thu, 21 Mar 2002, Peter Donald wrote: I think what Peter said was that you can read the spec only if you agree with the licence, and that prevents you from implementing it unless you follow all the rules. You can read the spec. You just can't use the spec to create a cleanroom implementation of the specification. You can still read it to understand how to use somebody else's implementation. Presumably, however, having read the spec, you are tainted. That includes the requirement to pass the official test suite, and probably other restrictions I don't understand. The problematic clause is this one, I presume: (vi) satisfies all testing requirements available from the Specification Lead relating to the most recently published version of the Specification six (6) months prior to any release of the clean room implementation or upgrade thereto; Presumably we cannot distribute the xml-apis unless we can meet this requirement of the spec. This page http://jcp.org/aboutJava/communityprocess/final/jsr063/ asserts that there is a JAXP TCK, although you can't seem to purchase it online. Other restrictions - who knows? When the spec says (vii) does not derive from any of the Specification Lead's source code or binary code materials;, it is not clear to me what that covers, especially in the case of JAXP where I think the RI comes from Apache, based on code originally contributed by the Specification Lead (Sun). Also there may be a specific Out-of-Band Sun-Apache licence in place as alluded to by Dirk earlier. It's obvious some of the people who worked on this did read the spec - so it seems this is not a legal implementation. If there is no specific agreement between Sun and Apache covering this, then I agree. The licencing and jcp lists are closed to the public, and this seems to be the job of the PMC and ASF ( to verify that all the software is legally used ). I can only hope a lawyer will be used to validate it. If this is not resolved - we have to start removing all dependencies to JAXP and all other APIs that are not legal, and eventually work on replacements. There is no other way. I presume you can still depend on JAXP without having your own clean room implementation, nor including it in a distribution. You would have to require the user to acquire their own copy of the jaxp classes/interfaces. I haven't seen any restrictions in the spec on linking. Conor -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- http://www.superlinksoftware.com http://jakarta.apache.org/poi - port of Excel/Word/OLE 2 Compound Document format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: LICENSE in .jar files
BTW. Define: release ;-) On Wed, 2002-03-20 at 19:55, Conor MacNeill wrote: From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Thu, 21 Mar 2002, Peter Donald wrote: I think what Peter said was that you can read the spec only if you agree with the licence, and that prevents you from implementing it unless you follow all the rules. You can read the spec. You just can't use the spec to create a cleanroom implementation of the specification. You can still read it to understand how to use somebody else's implementation. Presumably, however, having read the spec, you are tainted. That includes the requirement to pass the official test suite, and probably other restrictions I don't understand. The problematic clause is this one, I presume: (vi) satisfies all testing requirements available from the Specification Lead relating to the most recently published version of the Specification six (6) months prior to any release of the clean room implementation or upgrade thereto; Presumably we cannot distribute the xml-apis unless we can meet this requirement of the spec. This page http://jcp.org/aboutJava/communityprocess/final/jsr063/ asserts that there is a JAXP TCK, although you can't seem to purchase it online. Other restrictions - who knows? When the spec says (vii) does not derive from any of the Specification Lead's source code or binary code materials;, it is not clear to me what that covers, especially in the case of JAXP where I think the RI comes from Apache, based on code originally contributed by the Specification Lead (Sun). Also there may be a specific Out-of-Band Sun-Apache licence in place as alluded to by Dirk earlier. It's obvious some of the people who worked on this did read the spec - so it seems this is not a legal implementation. If there is no specific agreement between Sun and Apache covering this, then I agree. The licencing and jcp lists are closed to the public, and this seems to be the job of the PMC and ASF ( to verify that all the software is legally used ). I can only hope a lawyer will be used to validate it. If this is not resolved - we have to start removing all dependencies to JAXP and all other APIs that are not legal, and eventually work on replacements. There is no other way. I presume you can still depend on JAXP without having your own clean room implementation, nor including it in a distribution. You would have to require the user to acquire their own copy of the jaxp classes/interfaces. I haven't seen any restrictions in the spec on linking. Conor -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- http://www.superlinksoftware.com http://jakarta.apache.org/poi - port of Excel/Word/OLE 2 Compound Document format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: LICENSE in .jar files
On Thu, 21 Mar 2002 13:03, Andrew C. Oliver wrote: So could a non-tainted person through black box testing produce their own JAXP clone? I don't see how as they need access to Suns IP someway and there is no way to get a license to do that. Ie can't use spec without being tainted and can't use any *legal* implementation of spec because all legal implementations are not able to grant the right of reimplementation. I doubt that would hold up in court but it has held up various opensource projects that are actually concerned about legalities (see the GNU Classpath archives). Fun fun fun. -- Cheers, Pete ** | Trying is the first step to failure. | | So never try, Lisa - Homer Jay Simpson | ** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: LICENSE in .jar files
-Original Message- From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]] Sent: Thursday, 21 March 2002 1:03 PM To: Jakarta General List Subject: RE: LICENSE in .jar files So could a non-tainted person through black box testing produce their own JAXP clone? -Andy I don't know. IANAL. We really do need a lawyer. Anyway, in my view, you would not be able to legally run such a reverse engineered clone on a Sun JDK From the JDK 1.4 licence. Java Technology Restrictions. You may not modify the Java Platform Interface (JPI, identified as classes contained within the java package or any subpackages of the java package), by creating additional classes within the JPI or otherwise causing the addition to or modification of the classes in the JPI. In the event that you create an additional class and associated API(s) which (i) extends the functionality of the Java platform, and (ii) is exposed to third party software developers for the purpose of developing additional software which invokes such additional API, you must promptly publish broadly an accurate specification for such API for free use by all developers. You may not create, or authorize your licensees to create, additional classes, interfaces, or subpackages that are in any way identified as java, javax, sun or similar convention as specified by Sun in any naming convention designation. Conor -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: LICENSE in .jar files
-Original Message- From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]] Sent: Thursday, 21 March 2002 1:10 PM To: Jakarta General List Subject: RE: LICENSE in .jar files BTW. Define: release ;-) I guess it would be up to a court to define release :-) I don't know what it means :-) There are similar definition problems with terms such as distribution. Does providing a jar in CVS consistute distribution. Probably does. Conor -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: LICENSE in .jar files
On Thu, 21 Mar 2002, Conor MacNeill wrote: I don't know. IANAL. We really do need a lawyer. Anyway, in my view, you would not be able to legally run such a reverse engineered clone on a Sun You have a lawyer - or rather - the PMC has access to those beast. This is being worked on (even today - during the ASF board meeting) - and will be resolved. Feel free to keep bringing good examples of potential problems to [EMAIL PROTECTED] Dw -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jakarta Overview
Waldhoff, Rodney [EMAIL PROTECTED] writes: Re. Chris's point, I think we'll be hard pressed to reach consensus on what a project maturity means, let alone how to measure it. If I were building this document (and if I remember correctly, I built this document: http://jakarta.apache.org/commons/components.html, which is rather similiar in some respects), I'd stick to factual information--brief description, release dates/numbers, etc. and let the facts speak for themselves. +1 -- sticking to the facts leaves the evaluation of a package up to the consumer. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
