On Sun, 2002-05-05 at 01:54, Rainer Klute wrote: > People, > > I neither have the time nor the interest for taking part in a > lengthy discussion on little-endians. Here's the HPFS point > man's (e.g. mine) point of view: > > - Andy posted a bug that there should be only a single > little-endian package throughout POI. I accepted that bug (see > <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8354>) as > being a very valid point. >
That wasn't the beginning of this, but okay. > - I also said that I'd look at it when time permits and that > this bug is not an urgent one. So far no one disagreed. The > conclusion is that there is no immediate need for action. That > is, org.apache.poi.hpsf.littleendian will exist for quite a > while and then disappear. > Umm I now disagree. Its been quite a while. > - However, a piece of software who's days are counted still > needs to be maintained if an error appears. This is what Drew > pointed out and this is something I agree with. > -1, its my right to object. I object. I've given my reasons and alternative. > - We can now pick one of three options: > > - Integrate both little-endian packages, pulling together an > at least partly new API and make the rest of POI use it. I don't > oversee what amount of work this would be but I don't think is > can be done in an hour or two. Like Drew I also have my own > little schedule and cannot do this before middle of June. > > If anyone else has the time to do it: go for it. > I don't have time. But I'm making time. This is precisely what I'm doing. However I have to do this in pieces. My first step will be to remove the old so that I get compilation errors and my second step will be to fix them. If you don't like my method you're free to do it *another way*. > - Maintain org.apache.poi.hpsf.littleendian for the rest of > its lifetime. Maintaining means fixing bug but not adding > functionality (here: let DWord.intValue interpret the bytes > as an unsigned int and return that). Comments are not part > of functionality but could be misleading. Anyway, it does > not hurt to correct them. > -1, the cancer has grown. Its time to cut it out. > - Leave it as it is for the time being. Given the usually > small amounts of data in property set stream I guess the > probability for the signed vs. unsigned bug is relatively > unlikely to appear. > > These are the facts as I see them. You might see them > differently. However, a different point of view does not justify > any harsh wordings in e-mails. Showing the Big Hammer, threatening > to delete a package or saying other harsh words is only frustrating > and demotivating. > Sorry, maybe my colorful speech covered the simple facts: 1. We gave you time. 2. Its time to fix this. 3. I said if you don't I will. 4. I am now. 5. If you don't like how I'm going to do it, well your course of action is to make time and do it yourself. 6. De-motivating and frustrating you isn't my goal. Its fixing an important code quality issue. We can take a vote however if you read, +1 = "I agree and will put forward the effort", so basically its put up or live with how *I* do it. Sorry it has to be this way, Andy > Best regards > Rainer Klute > > Rainer Klute IT-Consulting GmbH i. Gr. > Dipl.-Inform. > Rainer Klute E-Mail: [EMAIL PROTECTED] > K�rner Grund 24 Telefon: +49 172 2324824 > D-44143 Dortmund Telefax: +49 231 5349423 > > > -- http://www.superlinksoftware.com - software solutions for business http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in Java http://krysalis.sourceforge.net/centipede - the best build/project structure a guy/gal could have! - Make Ant simple on complex Projects! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh
