Project Ragnaroek - The Road towards Midgard 2

Note: this document is still in proposal stage. Definite decisions on the roadmap towards Midgard 2 have not yet been made.

Updates:

2003-03-29: Added Martin's notes to Application server evaluation
2003-03-28: Added Alexander's notes to Application server evaluation

Project Ragnaroek

There have been several attempts at rewriting Midgard in the past, most notably the separate Midgard 2 development projects lead by Jukka Zitting (2000) and Ami Ganguli (2001). However, these attempts have not been able to produce results.

Important point here is that rewrites are very difficult for Open Source projects. Volunteer contributions usually rely on the fact that contributors can receive something immediately usable from their efforts. Because of this it is important to implement Project Ragnarok on existing infrastructure, minimizing effort needed for producing results.

What is Ragnaroek?

Ragnaroek (Ragnarøk) is the final battle between gods and giants in Nordic mythology. After the final battle a new world will be built on the ruins.

What is Midgard?

The first part in planning a rewrite of Midgard's architecture is to understand what Midgard actually is. In the discussions so far the following has appeared:

Midgard is a Web Content Management Framework for medium-sized websites
Midgard is simple and quick to implement
Midgard is international, enabling creation of global websites

Goals

There are several important goals for the Midgard rewrite:

Cleaner, more maintainable codebase (possibly using a scripting language)
Enabling creation of new Midgard object types
Fewer API dependencies
Persistent application server
Building on existing software
Multiplatform, easier installation
Moving MidCOM to Midgard core
Aligning Midgard more closely with the PHP community

Important considerations

Midgard has several important aspects that should be retained in the rewrite:

International support: UTF-8, Multilang
Keeping PHP as the "site development language"
GNU licensing
Repligard
Performance
Backwards compatibility (target: 90%)

Proposed solution

Proposed Midgard 2 architecture

Idea discussed by Henri Bergius, Torben Nehmer and David Schmitter in OSCOM Sprint Zurich was to base the new Midgard 2 on top of an existing application server. Ideas presented included Zope and JBOSS.

In this case the application server would provide data management services. Midgard API would be provided by a PHP-level library, preferably available from PEAR. The library would communicate with the application server using a RPC protocol like SOAP or XML-RPC. HTTP query handling would be managed by a lightweight Apache 2 module.

Using an existing application server would simplify development, as it would be only required to write the needed Midgard object classes for that application server. Also, since all data would be managed by the application server the PHP library could be relatively lightweight. Using an Apache module instead of mod_rewrite like Midgard Lite does would allow greater flexibility and keep the Midgard name in Apache response headers. Preferably Midgard 2 would be also runnable without the Apache module.