[mb-devel] Cleanup release

[Matthias Friedrich]

On Wednesday, 2006-09-27, Stefan Kestenholz wrote:
[...]
> Amongst the first things that should be done are to develop the ideas
> of the GreatDebate chat into useable tools. Currently, these are not
> more than sketchy concepts, which haven't yet been tested if they
> actually work. I said it before, but i still do not like the
> implications that the developers should subject themselves to a code
> of conduct which might significantly impair the source of satisfaction
> that comes with working under the open-source terms: One has to be
> able to decide certain elements of how one wants to work with the
> project, i'm a bit tainted i have to admit, but Matthias has a similar
> opinon, afaik. Now, enough politics, this is what i would recommend.

I fully agree, I have stated this opinion several times already (the
last time was on the blog).

> 1) Setup the communication protocols discussed in GreatDebate (Forum, etc.)

Personally, I don't like forums much, but I agree they could help MB a
lot. Those people who don't want to (or can't) code can be made forum
admins and still help the project in a way. The forums release would
also be something that buys time for mb_server work.

> 2) Given that the community is generally quite happy editing away
> since the dicussions quieted down, and no serious problems arised -
> Fix UI bugs, and small business layers issues, and do another
> maintenance release.

Yup. This could include the fixes to INSTALL and the simplified setup
for replication feed users and new developers.

Also, a cleanup of the moderation subsystem would be plus; just have a
look at Moderation.pm. The AR support is also a bit sketchy and very
hard to understand and maintain.

> 3) Define which parts of the NGS will be built physically, and which
> ones semantically

> 4) Develop database schema which models 3)
> 4.1) Asses possibilities to port data to a enterprise level RDBMS like
> Oracle, MsSQL.
> 4.2) Assess how the data could be migrated from the current to the new
> database schema at a given time t (At time t-1 week, set database to
> readonly, and ask editors to vote the pending edits through. At time
> t, scripts would be used to import the data into the new schema and
> create the parent entities according to 3))

I disagree with 4) for practical reasons. There is more Postgres
knowledge in the OS community, because you get the database for free
and your distribution helps to set it up easily. Getting Oracle up
and running with apropriate performance is difficult, although it
outperforms Postgres when configured by an able admin.

> 5) Start work on a business layer, which does not build on the current
> mb_server codebase but uses state of the art Java (alternatives?)
> architecture. This means:
> 5.1) Use a proven and robust concept for the future mb_server iterations:
> * Model-View-Controller Pattern (Struts / Java Server Faces)
> * Object-Relational mapper (Hibernate)
> * POJO Business layer (EJB is too complicated for MB's scope, IMO)
> 5.2) Service-oriented design, ie. "create releationship x to y" which
> could be used by all kinds of business objects.
> 5.3) Future proof architecture which deals with all kinds of entities,
> not restricted to the entities we have today.
> 5.4) Implement unit tests, automated testing

A huge task, but certainly the right thing to do. The world has turned
since the late 90s but the Perl/Mason combo is still stuck in web
development stone age (not to mention that perl 5 is a zombie). Today,
even smaller webapps are built using a Model 2 architecture, OR mapping
and Unit Testing. The separation of display logic from business logic
is a proven concept and it should be used in a project as big as MB.
Anybody who disagrees here should definitely pick up a book (or read one
of the many Model 2 intro articles out there) and update their knowledge
about web applications.

Going down this road is an experiment, however. Nobody knows if we can
get enough competent volunteers to take this on. With Stefan probably
unmotivated and me working on my diploma thesis, two developers with
knowledge in this area are unavailable already. I'm sure Luks is
competent here, too, but he's working on picard and libmb3 (without much
help BTW) and thus overloaded. There can still be a useful experiment
though:

How about creating a POJO model that covers the MB domain (for the
start without the moderation subsystem), create Hibernate mappings
and port the new web service to it? Like that, MB can evalutate these
technologies without much risk and still gets a product out of it. I can
imagine the business and persistence layers would be a nice thing for
customers, too.

If this works, performance is good etc., we can think about moving over
more of mb_server.

Regards,
	Matthias