>I find that approach a little bit too gun-slinger in the wild-west. If this >was just an application, I wouldn't see as much of a point for component >specification. >However, this is an SDK. More developers are interested in >our component specifications than just those who want to check out the apache >code. We have strong >backwards-compatibility requirements, and having a wiki >where the API proposal is clearly laid out with possible issues makes sense to >me. Of course one of the >main reasons I favor this approach is just that >personally I find it extremely hard to follow the discussions on an email >thread.
I think my bigger point is that you can write all of the specifications you would like and that can be part of the process. No objection there. However, if someone contributes a working component without any of this work, or that runs contrary to this work, and yet it still meets the requirements for the project as a whole, I would vote for it. What you are proposing is what I wanted to do with Spoon. In that environment and in that direction I agreed with it. To me though, Apache is a bit more wild-west, however, it is the belief that order and direction comes from that chaos. Further, it often takes less time to write code, see the real issues and argue about the actual lines of code than argue about a theoretical specification. I am currently changing the compiler in ways that will likely take 3 years off Alex's life when he sees it. Its not that I expect all of these things to pass muster, but we have been arguing about them theoretically for years. I cant wait to have the arguments when we can test the code. Test the performance. Verify the functionality and demo the approach. Mike
