This one time, at band camp, Ilia Iourovitski said: Please see comments inline.
II>1.Castor/Intalio is not the first Open source project who run out money/resources and need active community to stay alive. The TCL/TK (or Python) community could be used as example. Both of them adopted mechanism of Enhancement Proposals, which consists from Abstract/Specification/Rationale/Reference Implementation. Just one look at PEPS or TIPs http://www.tcl.tk/cgi-bin/tct/tip/ gives understanding about directions of those communities. This is very interesting. It gets more into a formal mechanism for adding features. It certainly works with the Apache project. However, I suspect others may object. The reason I say this is due to the exceptions to splitting the castor-dev list into many lists - more work, cross posting, much more difficult with which to keep up, etc. I see both advantages and disadvantages. II>2.Another projects (most notably in Jakarta land) has sandbox(scratch pad) directory in CVS where developers can put experimental code. II> II>3.Features. Adding more and more features to the current code base will only creates more bugs and makes II> II>Castor even more slow. The current code base should be cleanup from commented code and the classes which has major number of bugs refactored. The main line of Castor development should be changed from II> II>adding more and more sweet features toward modularithation. Pluggable cache, datasource, query model (OQL, SQL, SODA). Currently Castor JDO build as one monolithic product.It is not possible to access lower level of Castor JDO for performance reason. II> II>4. Performance: In my test Castor JDO around 2 times slower than jdbc when retrieving 1000 records from database using one class per table mapping. It getting worse in case of many threads. The Torque and OJB II> II>have 10-20% difference with jdbc. This needs to be improved by pregenerating code, using BCEL for byte code insertion. This is *exactly* what the refactoring is about. Modularity, increased performance, etc. Unfortunately, many different circumstances have affected movement on this front. I say it's high time we branch and get this rolling again. Ilia, I am certainly interested to hear more about your thoughts on pregenerating code and manipulating byte code. II> II>5. Directions: Typically database applications falls into three flavor with different requirements: II> II>a: Using RDBMS to store application configuration. Typical case - Personalization system which keeps data about customers, products, prices, and so on. There is rich class hierarchy, data read on start of system, wrote on shutdown. Data rarely updated. Data must be cashed. This is probably was design goal for Castor. II> II>b: Heavy transaction processing, like credit card processing. Small number of table/classes, simple binding, tons of threads. In current version Castor not well suited for it because it is trying to keep one object for particular id in jvm, which let to synchronization/deadlock in concurrent transactions. Especially when some transactions are reading and another writing data into database. II> II>c: Reports. Many joins and needs to get big junks of data from database quickly. Data required sorting, grouping. II> II>it is not feasible that Castor JDO can feed all of them at one time, so probably it should be position as framework which can be fine tuned for different needs. Like if I need to unload data from database for performance reasons it would be nice to Service Providers directly, bypassing locks, caches, etc. Right! And this is where modularity would help tremendously. The best example I can think of at the moment is JBoss. It is very modular, very flexible, it offers the ability to plug/unplug certain things (including Castor JDO). Here is one idea and it is *purely* a hypothetical: if the Castor CVS tree was logically split into a few smaller projects with certain people working on each project (again, my reference here is JBoss) - building each as a separate project as well as all together as one project for distribution via Ant (and maybe Buildmagic) we could achieve modularity. It would also provide a more logical separation. This would certainly require more people on the team, but I think that it would skyrocket the development time as well. Each module or sub-project could be designed to be built and tested independent of the rest of the architecture. However, there would still need to be black-box tests for the entire architecture together. I may be fired up about nothing here because others won't like the ideas. But I really believe that we've hit upon something here. Committers, community-members, Ilia, what say you? Let's truly brainstorm about this and see where it goes. Bruce -- perl -e 'print unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");' ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
