[mb-devel] Cleanup release

[Stefan Kestenholz]

> I would like to hear more about your thoughts about a cleanup
> release. Can you please elaborate more on what you think should go
> into such a release?

I'm answering to a private message from Rob, and even if he
specifically asked for Matthias' thoughts in this thread what such a
cleanup release would encompass, here are my suggestions/comments.

First things first: There are so many loose ends currently, that it is
not a good idea to dive into further restructuring of the server
codebase right now. I have exact the same reservations as Matthias'
given the mb_servers readyness for the NGS.

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.

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

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.

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))

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

6) Transitory steps
6.1) Define interfaces between current UI (perl/mason) and Business Layer
 * Business layer would at the first stage mean code which enters
edits, ie the parameters passed in to the /comp/entermoderations
component
6.2) Adapt mason pages to use the interfaces (webservices for the
transitory phase)
6.3) Do a release, which does not add functionality, but uses the new
architecture and new database schema. All new entities of the NGS
wouldn't be editable at first, like discussed at the Summit.

7) Port UI elements which are not related to NGS to the
MVC-architecture, maybe sneaking in a little ArtistPageRedesign.

8) Empower users (would start in parallel to 2)
In the meantime, users which until now haven't been able to dive into
server development because of the complexity ( ? or just because its
perl :-) ) could start work on user interface elements for NGS. These
could be done in plain html, and then implemented once the
architecture is ready. The biggest hurdle in implementing the NGS is
definitely the user interfaces, it won't hurt to put lots of time into
the basic UI, before actually implementing it.

9) Implement new NGS elements, one at a time

If we followed this timetable, there would always be something to do
to keep the users (who like to be) involved, while also ensuring a
smooth transition to a future proof architecture (this means toolsets
which have a wider acceptance, invest in a better database). Its not a
coincidence that one doesn't see much big projects with perl/mason
architecture (at least i haven't), i think its time to make a big cut.
Whatdda think?

regards,
keschte