>>You did, I did it to collaborate in finishing the work. Because no one under stands this >>underdocumented piece, no one could work on it but you. Catch-22. >> >>If I kept the code locally, no one could help finish this right? right.
No. There is *never* any reason to check in broken code. I have worked on several projects with a resource management system, and this is always a very critical point. If you break something a lot of other developers are concerned. You'd never to this. The way to go is to give your work to your co-developer by some other means, i.e. private e-mail, a temporary CVS branch, module, or server, or whatever. But you will never check in broken code. At the time you checked in the broken code you should have known that I could not donate *any* time to HPSF, not even to check whether your changes were okay or not. I think I had made this clear in advance. >>>It was you who hesitated to do that changes, not me. As I pointed >>>out in my original posting, there was no reason to hesitate. No >>>one would have noticed any performance degradation if the code >>>would have been left unchanged for 5 years. >>> >>>You broke HPSF. This fact speaks for itself. >>> >>> >> >>Yup. I'm the only one who's worked on it recently. >>... Oh, well, what a cool argument! :-) I'd prefer old code that works over new code that doesn't. But I understand we cannot come to a conclusion. >>>I'll do that if I have a clean and working code base. >>> >>> >> >>Well rainer, you don't want to help getting there with one method of one clas s. You put it too simple. It is not just one method in one class. It is all the general little-endian classes and the way they work versus the HPSF classes. This takes more than snipping your fingers. (As you found out.) >>So >>we go back to the issue whether you want to do this collaboratively or if its your >>pet project? >>Help me fix this one tiny little underdocumented method, and le ts move on. I agree with you on fixing this issue, I just want it to do differently than you. You accused me that my pride was hurt and that HPSF were my pert project. However, it seems that this is true for you regarding your "fixes". Let me do it and you'll all get quality code and documentation. >>You're not willing, but it sounds like with Ryan and Glen's help we may be ab le to get this >>done anyhow. so this is moot to me. I am willing, but sticking to quality first. Then follows code reuse etc. >>>-1. HPSF must be fixed *immediately*. Rolling back to the old >>>revisions can be done in an instant. Anything else would first >>>require me to understand the general little-endian classes, consider >>>whether they suit my need, probably adding some functionality >>>to them - and eventually the general classes and the HPSF classes >>>might be incompatible and thus might require a major code rewrite. >> >>That is a rediculous estimate. What you're doing is parsing little endian va lues, >>writing little endian values. These may be signed or unsigned. Anyone else pipe up if >>this sounds like a major ordeal, perhaps I'm dull, but this sound pretty dern generic. May be. But it surely takes longer than rolling back the changes and *then* considering the details. It might well be that your changes are the solution. They are not lost when rolling back. But I'd want working code first, and *then* fixing stuff with junit test at hand. >>>What we need now is a quick action to get HPSF working again. Any >>>other action can be taken afterwards. >>> >>> >> >>No. I disagree. We need to make HPSF into a real POI component that others can >>collaboratively work on, that fits in with the common facillities of the proj ect, that >>meets community standards... Otherwise it needs to go in the scratchpad. If we move it >>to the scratchpad, you can do whatever you like with it. Maybe one day you'l l have enough >>time to achieve this alone. You make two statements in one here: 1. You say its okay that HPSF continues to be broken for some time and does not need an immediate fix, i.e. within a few minutes. I don't agree. 2. You say that HPSF should be a POI component that we can work on collaboratively. I do agree. But please keep these two different statement apart! >>But at the moment with Ryan and Glen's help I'm confident we can fix this sin gle method and >>get this up and running so HPSF works. From there if you feel that is not a clean enough base >>to work with then I don't know what to say. I am sure Ryan and Glen are both able to do this. However, I can imagine that it were more effective for the POI project as a whole if they forstered the HSSF and HDF components instead of fixing HPSF. As I said, I am offering my time and effort to continue working on HPSF. Take it or leave it. >>Rainer, look at the list and the feedback you're getting. No one understands why fixing >>this method is such a big deal (including me), no one unstands (including me) why using the >>same classes that serve 3 other POI apis don't serve this one. Agreed. What I don't understand and never understood why this has top priority for you, even over test cases and documentation. >>Yes its broken, help fix it. 1 method. est 30 minutes for someone who under stands what it does. >>But between the three volunteers, (which is awesome), I'm confident we can fi gure this out. Surely more than 30 minutes. And you cannot be certain that everything else works as expected. But anyway: I am ready take your changes as a basis for my fixes. All I ask for is to bring HPSF back into a functional state before I do the fixes. Is this really too much to be asked for or in any way unusual? >>>Currently I have time. It is up to you if you take. I am not >>>married with HPSF. >>> >>> >> >>Rainer, I barely care currently. Make your choice, work with us or not. Sur ely you see >>that the little effort you've put forth does not make a divorce that serious of a threat. >>I hope it doesn't come to that, but in the end I have to respect a man of his word. >> >>Rewriting HPSF versus having this argument with you everytime I want to get a nything done (my >>next steps were to add unit tests, then docs, then write capability) in this area and having >>code that I can't understand or modify (which do note I don't have this compl aint with HDF, any part of >>HSSF, POIFS, etc), and the "you're way or the highway" approach... you don't want to work with >>me but you "don't have time" to do it yourself... Its a tough decision if yo u put it that way, the >>cost benefit analysis is not back yet on this issue. >> >>I continue to hope it doesn't come to that, but I'm not going to bend over un do my work just >>because you're upset and don't feel like helping me fix this method or at lea st helping me >>understand WTF it does. I commented on that already: I don't care about pride, self-determination or whether something is done my way or your way or anybody else's way. But I care for quality! That means that the code must *work*. And if the code does not work, those measures must be taken that get it working again with the minimum of time. This is getting the working HPSF revision from the CVS. >>>Andy, if you have problems to understand that class, you should >>>read the HPSF documentation, especially >>><http://jakarta.apache.org/poi/hpsf/internals.html>. <http://jakarta.apache. org/poi/hpsf/internals.html%3E.> >>> >>> >> >>you mean this one: >> >>ClassID >> >> >> >>0x00000000000000000000000000000000 >> >> >> >>Most property set streams have this value but this is not required. >> >> >> >> >>how does that help me? No, I did not mean this because it really does not help you and it is in a different context. I meant this one: Following the header is the section list. This is an array of pairs each consisting of a section format ID and an offset. This array has as many pairs of ClassID and and DWord fields as the section count field in the header says. The Summary Information stream contains a single section, the Document Summary Information stream contains two. ... 0xF29F85E04FF91068AB9108002B27B3D9 for the single section in the Summary Information stream. 0xD5CDD5022E9C101B939708002B2CF9AE for the first section in the Document Summary Information stream. Best regards Rainer Klute Rainer Klute IT-Consulting GmbH Dipl.-Inform. Rainer Klute E-Mail: [EMAIL PROTECTED] K�rner Grund 24 Telefon: +49 172 2324824 D-44143 Dortmund Telefax: +49 231 5349423 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
