Hello,
Let me first applaud you on the amount of effort you are putting into this proposal. It clearly shows that you are giving this a lot of thought.I feel that you are generally on the right track with the proposal that you made available at http://gsocopenfire.wordpress.com/2010/04/05/gsoc-proposal/ but I do have a number of reservations.
You need to get this right, given the nature of the problem and the severe impact to the project that the solution is likely to have. There’s most likely no going back after we release code based on your modifications in the source of the project. Apart from this, you’re also petting the belly of my pet project. I feel strongly committed to solving the problems that have been outlined. Given all of these reasons, I will be brutally honest in my comments. None of my comments are intended to scare you away though. Please view them as challenges.
The subject that you are tackling is a very complicated one. I believe that this particular problem calls for *expertise *on a number of subjects, including:
- Concurrent programming in Java
- XMPP (specification) theory
- Intimate knowledge of Openfire’s internals
The proposal that you have drafted shows that you have looked into the issue considerably. It does not (yet) give me the “this guy is an expert that we need” feeling though. Perhaps this is not fair, as the proposal is (a) a first draft, (b) not a detailed design (it’s not supposed to be) and © you’re no Openfire veteran, but as I said - brutally honest. To give you an example: you get into design details in various parts of your proposal draft, describing sensible techniques, but you do not base your descriptions on documented Java patterns or techniques. I’m not sure if you did this intentionally, if I’m missing obvious references (hey, I’m not perfect ) or if you are not familiar with these patterns. If the latter is true, then there’s a lot of documentation available to get you going. I can warmly recommend reading “Java Concurrency in Practice” by Brian Goetz. The JCiP book will provide you with a lot (if not: most) of the building blocks that you will need during implementation of whatever solution you come up with. The same person has authored a number of interesting reads at IBMs DeveloperWorks website, titled “Java Theory and Practice.”
I particularly like the first part of your proposal. What I like less about the proposal is that you seem to be committed to a solution already. Given the inherent complexity of the issue as described above, no-one can expect you to have a solution ready. It is good that you have one (or more) suggested ways to tackle this problem, but I feel that your proposal should focus a lot more on finding the solution to the problem, rather than to implement the solution. Lets not cut corners! I suggest that you identify alternatives and/or describe how you will identify these alternatives, their plusses and minuses, their risks, impact, and side effects.
This project is going to be a big one. Apart from that, you will run into unforeseen challenges. I would go as far as to say that it is quite unlikely that you (or anyone else) will deliver a finished, revised version of Openfire that completely fixes the Achilles’ Heel problem by the end of the GSoC period. The time is simply to short for that. This is perfectly acceptable though. What you do need to provide in your proposal is a solid project planning. How will you divide this project into phases or sub-projects? What will you do in each phase? In what order will you execute the phases? Are phases depending on each-other? Which phases will you complete during the GSoC period, which ones would you like to complete if there’s time left (yeah, right), and which ones won’t be completed as part of your GSoC project? From that last category, which ones are important to have done afterwards, and which ones are of less importance? And so on, and so on.
As towards Slicers comment regarding testing, I’m biased. On the one hand, you will need to be able to verify your solution. This is evidently important. On the other hand - I have never seen a full-fledged testing setup that accurately simulates the oddities of a production environment. Development of such setups are almost always a waste of time. I suggest that you focus on verification of your solution (does this or that technique give me the safety/performance/whatever that I require), not on simulation (let’s try to find out what happens if 20.000 people send random stanzas at the same time). Not having resources available to do testing is not an acceptable argument here though - you have an entire community to your disposal! There will be a number of people happy to help you run tests. You *will *need to prepare those tests and tell us what to do, of course.
On a completely different note: I think you should submit a proposal to the GSoC project page soon. Your potential mentors will be able to read it there (not all of them read IgniteRealtime) and can provide you with valuable feedback before this weeks deadline passes. Feel free to link to this discussion.
In conclusion, I believe that this proposal has a lot of potential. I believe that there’s a lot to be done, but I think you can be able to make this work! Please, continue!