Hi I can't help noticing that step 13, wich is like 'the other half' of the project has no real planning yet. This is probably ok, sinds all the other stuff has to happen first. Still I am very interested in this step, and am looking forward to any specific idears in this direction. Personally I have (unfortunately) not much experience with these matters, but I feel it is a very important step for mmbase, becouse at vara I notice that there is a mood of disapointment about mmbase on account of the fact that there are so many performance/stability (notice the distiction) problems. I feel these sentiments must be helped to change soon, or mmbase will lose credit. Allso I am trying to get vara to be sponsor for this project. I can't say anything about the outcome, but we will see. Regards,
Ernst > -----Oorspronkelijk bericht----- > Van: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Namens Pierre van Rooden > Verzonden: vrijdag 24 september 2004 10:49 > Aan: [EMAIL PROTECTED] > Onderwerp: Optimalization Project, Step-By-Step > > > I am restarting the optimalization project (formerly known as the > cleaning project). > I will be coordinating the execution, and will be recruiting > people to > work on this project. To do, I created a step-by-step plan to perform > all the necessary tasks. > The steps are followed below, in the order in which I expect them to > finish. Some steps can actually start earlier, but since they involve > the entire code tree will likely not be finished until much > later, and > an actual effort to finsih those tasks will be done after some big > moving/cleaning have been performed. > > A number of steps will be so involved that they will need to > claim CVS > for their duration, to avoid conflicts. > These steps are indicated below. when such a Step starts, I > will send a > mailing to the developers list to indicate which parts of the > code tree > will be resreved for the prohect, and for what dirationm. > This will gibe > peopel time to cehck in any bugs or last-minute changes to their own > projects. For the duration of the step, changes to that part > of the code > in CVS need be coordinated with the project coordinator. > Hoepfully these > periods will be short. > Note that for the duration of these steps, no guarantee can > be given to > the stability of the CVS. When a step is closed, source in > CVS should be > stable (at least be able to compile, and free of bugs > introduced by the > change). > > Not every step is fully detailed - class lists are not yet up to date > and some code needs discussion. > Where I believe discussion is needed, I listed it below. > > Every step will get its owen documentation page in the project page, > with info on people involved, date staretd/ended, and all > info needed to > fulfill the task (class lists, notes on problems, bug references). > > Some specific steps need to be voted on (noted below). > However, a lot of elements should probably be not be voted on > as single > entities, since that will slow down the project conciderably. > If people desire votes anyway, I can ask a vote for each > step, providing > a list of changes, but I don't think that will be helpful - > this project > will change a lot of things and as such voting is not the bestw ay to > aprtic[pate. Instead, if you want to avoid any of the many smaller > changes (such as the removal of a deprecated method) you can join the > project team. > > As a side note, unless people indicate a need to vote on each step, I > plan to run STEP 1 today, as it has little real impact (all > functionality in the old storage classes are also present in the new). > > Below is the outline of the steps. You are welcome to send in > additional > changes. Please note that while most of the code is tagged, not > everything may be up to date. > > The following stages in the optimalization project exists: > > STEP 1 > Remove deprecated storage/database code [1]: > Remove the old storage classes > This includes the following sources: > - org.mmbase.storage.Storage > - org.mmbase.storage.Transaction > - org.mmbase.storage.database.* > - org.mmbase.util.DatabaseLookup > and config: > - database/hsqldb-storage.xml > - database/mysql.xml > - database/postgresql.xml > - database/relation.xml > - database/lookup.xml > - database/lookup_postgresql.xml > - database/README.TXT > References to these classes should be removed (i.e. in MMBase.java). > > STEP 2 > Move out all SCAN code to a seperate application. > Some code may be tagged with @application SCAN. > This also includes : > - org.mmbase.module.gui.html.* > - org.mmbase.util.scanpage > - various classes used for generating HTML in org.mmbase.util > In addition, several issues will need to be solved, such as > references > to scan classes in MMObjectBuilder, ProcessorModule, etc. > This step needs a meeting on the removal of classes such as scanpage > before it can be started. > This step may also need a proposal and a vote if interfaces > are changed. > > STEP 3 > Move any remaining code that belongs in an application, > rather than the > core. > Create appropriate applications. > Code is tagged in MMBase using @application > A list of tagged classes will be provided. > Some code may not be tagged yet - these may be removed or moved to a > 'tools' application after debate. > This step needs a meeting on what applications to add before > it can be > started, and likely discussion by email/irc on further implementation. > > STEP 4 > Adapt code to use SearchQuery, and remove any direct references to > MultiConnection. > This includes classes tagged with @sql, but also any code that calls > MMObjectBuilder.search() with hardcoded SQL. > This step needs a discussion (possibly irc or email) on the > removal of > methods from MMObjectBuilder before it can be started. > > STEP 5 > Remove deprecated storage/database code [2]: > Remove the database support classes: > - org.mmbase.module.database.support.* > This also involves removing all references to MMJDBC2NodeInterface, > replacing it with calls to either serachquery or the > storagemanager. This step needs a meeting on remaining > storage issues in the new layer > (what to solve now and what later) before it can be started. > This step needs a proposal and a vote to allow for the > deletion of the > support classes. > > STEP 6 > The JDBC Module should be re-evaluated, and possibly moved to > org.mmbase.storage.implementation.database.JDBC. > This step may need a proposal and a vote if teh JDBC module is > significantly changed. > > STEP 7 > Change classnames, move classes, and change package structure > where this > makes sense. > Code is tagged in MMBase using @rename or @move > A list of tagged classes will be provided at: > http://www.mmbase.org/?docnr=33149&template=%2Fincludes%2Fdoc_ > index.jsp > This step needs a proposal and a vote to move and rename classes. > > As of yet, moving code from org.mmbase.module.core or > org.mmbase.module.corebuilders to org.mmbase.core is not yet > contemplated. This step needs a proposal and a vote to see if > that specific move is > something we want to do in 1.8 > > STEP 8 > Remove all deprecated code (methods and classes), and solve > any issues > that occur. > Remove any remaining legacy code from the VPRO. > ALso move any code if that makes it more generic, and remove any > duplicate code. > This can be done during the whole project, but a final pass should > ensure that this is done everywhere. > Code is tagged in MMBase using @deprecated or @deprecated-now, > @dependency, @duplicate, and @vpro > A list of tagged classes will be provided at: > http://www.mmbase.org/?docnr=33151&template=%2Fincludes%2Fdoc_ index.jsp STEP 9 Solve all issues with configuration and use of member variables. Make use of the resourceloader for configuration where possible (if the resourceloader is accepted as a Hack). This can be done during the whole project, but a final pass should ensure that this is done everywhere. This includes scoping issues, as well as the use of badliterals or the use of variables that are not configurable. Code is tagged in MMBase using @scope, @bad-literal, and @bad-constant A list of tagged classes will be provided. STEP 10 Remove all use of deprecated code. This can be done during the whole project, but a final pass should ensure that this is done everywhere. This includes use of any code that was deprecated bu Sun, and that shows up when compiling with deprecation on. STEP 11 Apply Code Conventions, and add javadoc. This can be done during the whole project, but a final pass should ensure that this is done everywhere. Code is tagged in MMBase using @code-conventions or @javadoc A list of tagged classes will be provided. See also: http://www.mmbase.org/?docnr=33153&template=%2Fincludes%2Fdoc_index.jsp STEP 12 Apply internationalisation where possible. This may be only possible in limited cases, and it is possible we skip this step, or leave it to the internationalization project. This step may need a meeting. STEP 13 Find performance issues and improve these. Use of a profiler may be useful in finding issues.
