I think this is _exactly_ the kind of organization Castor needs. As a user and sometime participant in the project, the lack of clear information on who's responsible for what and who is working on which tasks makes it very daunting to propose fixes or new development ideas.
I've had some experience with Jakarta-based projects and Jboss. The compartmentalized CVS structure and overall project organization I think makes it easier for new users to figure out what's going on. --Kevin -----Original Message----- From: Bruce Snyder [mailto:[EMAIL PROTECTED]] Sent: Friday, April 26, 2002 9:38 AM To: [EMAIL PROTECTED] Subject: Re: [castor-dev] Castor JDO Status 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 II>money/resources and need active community to stay alive. The TCL/TK II>(or Python) community could be used as example. Both of them adopted II>mechanism of Enhancement Proposals, which consists from II>Abstract/Specification/Rationale/Reference Implementation. Just one II>look at PEPS or TIPs http://www.tcl.tk/cgi-bin/tct/tip/ gives II>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 II>pad) directory in CVS where developers can put experimental code. II> II>3.Features. Adding more and more features to the current code base II>will only creates more bugs and makes II> II>Castor even more slow. The current code base should be cleanup from II>commented code and the classes which has major number of bugs II>refactored. The main line of Castor development should be changed II>from II> II>adding more and more sweet features toward modularithation. Pluggable II>cache, datasource, query model (OQL, SQL, SODA). Currently Castor JDO II>build as one monolithic product.It is not possible to access lower II>level of Castor JDO for performance reason. II> II>4. Performance: In my test Castor JDO around 2 times slower than jdbc II>when retrieving 1000 records from database using one class per table II>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 II>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 II>flavor with different requirements: II> II>a: Using RDBMS to store application configuration. Typical case - II>Personalization system which keeps data about customers, products, II>prices, and so on. There is rich class hierarchy, data read on start II>of system, wrote on shutdown. Data rarely updated. Data must be II>cashed. This is probably was design goal for Castor. II> II>b: Heavy transaction processing, like credit card processing. Small II>number of table/classes, simple binding, tons of threads. In current II>version Castor not well suited for it because it is trying to keep II>one object for particular id in jvm, which let to II>synchronization/deadlock in concurrent transactions. Especially when II>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 II>database quickly. Data required sorting, grouping. II> II>it is not feasible that Castor JDO can feed all of them at one time, II>so probably it should be position as framework which can be fine II>tuned for different needs. Like if I need to unload data from II>database for performance reasons it would be nice to Service II>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 ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
