Emile: That's a big one. Midgard in general is so darn flexible itcould very well become the Emacs of web serving, so listing what it*can* solve would be a daunting task.
What Midgard brings me is power without hassle. The most importantthings (access control, site maintenance, style system) are built-inand easy to use from the standard maintenance site.
On the other hand, if I need something esoteric, the foundation isthere to build it. Midgard at its core an API: even the Midgard adminsite, which looks & feels like it's an integral part of Midgard, is'just another' Midgard application.
Jukka: This project started from the need to create a dynamicdatabase-driven Web site using freely available components. Instead ofcreating yet another ad hoc PHP/MySQL Web site, we decided to firstdesign a generic framework for building such Web services and thenimplement our Web site using that framework. Midgard is the result ofthis process.
Midgard allows one to create and maintain dynamic Web services withouta thorough understanding of database design methods and thecomplexities of maintaining persistent database connections. On top ofthat we added an intuitive and extensible style system, user accountsand a generic content model based on articles in different topics.
Jukka: Both application servers aim at easing and automating theprocess of creating and maintaining dynamic Web services. Theapproaches taken by these two projects are however quite different.
Zope uses python objects as the basic building blocks of the Webservices. This is a very dynamic and also quite code-oriented methodof web publishing. In Midgard the emphasis is on the different datarecords that are automatically bound together to produce Webcontent. PHP code is used in Midgard as an extra for adding dynamiccomponents to the Web sites, not as the basic building block.
You can use the Midgard's host and layout systems to easily create andmaintain Web services without any programming skills required. Theintuitive style and template system allows you to easily work andexperiment with multiple different site styles.
Henri: I think also an important difference between Zope and Midgardis that Midgard is based on Apache, and can be easily plugged in to anormal Web server configuration. This provides users with an easyupgrade path from their old Web solutions to Midgard's dynamicmodel.
Jukka: Midgard consists of four components, the database, the corelibrary, the mod_midgard translation module and the midgard-phpcontent generation module.
Midgard uses a relational database for storing all content. Thedatabase consists of a set of tables that store Midgard records likearticles, persons, hosts and styles. Midgard uses the MySQL databaseengine instead of an internal database format for handling therecords.
The core functionality of Midgard is hidden in the Midgard library. Ithandles the basic tasks like database connectivity, userauthentication and authorization. The library is evolving to provide ageneric API for handling the objects in the Midgard database.
The mod_midgard translation module is the workhorse of a Midgard webserver. It is an Apache module that maps URLs to Midgard databaseaddresses and collects all the style elements needed for pagegeneration. The module also handles the initialization and terminationof the persistent Midgard database connections.
After the translation module has mapped an URL to a Midgard pagerecord and collected all the required style elements the Midgard-PHPmodule takes control and generates the actual HTML page that is sentto a browser. Midgard-PHP is a patched version of the official PHP. Itis fully compatible with normal PHP. The added features are thefunctions for handling Midgard records and the Midgard template systemthat allows the page to be generated from a collection of style andpage elements.
Jukka: The Midgard database was initially designed to be used onlywith MySQL and therefore contains a few MySQL dependencies. Thosedependencies can however quite easily be replaced with standardconstructs. The next major version of Midgard will work with anystandard SQL database.
A standard-conforming database layout is only the first part of truedatabase independence. Instead of writing separate code for each ofthe numerous client APIs of the different database engines, we'vedecided to use the ODBC generic database access mechanism. ODBC allowsus to write the database access code once and allow Midgard users toplug in the database engine they like.
The Open Source ODBC packages iODBC and unixODBC have made it possiblefor us to develop and experiment the Midgard ODBC code. The eager andcompetent support from both the ODBC teams has helped us a lot.
Emile: While there aren't too many DAV aware clients at the moment, Istrongly feel WebDAV is going to be big. The DAV protocol is going toenable clients and servers to cooperate better and easier for the sitemaintainer, without getting tied up at either end. FrontPage doneright, you might say.
Any server offering DAV support is going to have a huge advantage, butimplementing DAV is a pretty large task. Most current implementationsact on the simplest case, the hierarchic filesystem(like) database,assuming most content is static. This is not a paradigm very wellsuited for a largely dynamic site. Midgard is going to have DAV, butwe're going to get it right, so this might take some time.
Emile: Better than one could hope for on our resources, not as good aswe'd like. Documentation is essential but rather low-profile, so manyview it as a non glamorous job. This needs more PR in general, Ithink.
Another problem is that many people feel that they don't understandthe technology, and therefore can't document it. This is entirelyfalse: in my opinion, the people who understand the technology bestare the worst people to document it. Yes, you really, *really* needthe help from the techies, but you want the documentation readable fornon-techies. The only way to get this right is to have someone workingat it who needs to ask at every step "why did they do it this way? Howdoes this *work*".
Henri: While the documentation is still in a sorry state, I thinkwe've got our needs covered in other areas quite nicely. Jukka handlesthe core libraries and some other people are doing research onpossible new features and additions (for example, Emile's work withthe DAV support). Of course, having more people in the projectwouldn't hurt.
We used to have on our site this list of things we need help with, butI believe it is now quite outdated. I'll do something to it during theweekend, and maybe post some information in the next MWS as well.
Jukka: The short term goal is to make Midgard inter-operable with awide variety of environments. The forthcoming 2.0 release will useopen standards at all levels. New features include ODBC for databaseconnectivity, XML for packaging format, PAM for authentication, CORBAand XML-RPC for desktop integration, and DAV for content management.
After the 2.0 release has laid the groundwork for extending Midgardwe'll concentrate on the end-user features of Midgard. Goals for theyear 2000 include support for mobile computing and PDA's, integrationwith desktop software, better content management tools, and perhapswork-flow and other advanced business features.
Henri: The Midgard releases are usually named after some real-worldevent or object that has affected our development schedule.
For example, the "Mad King" release was named after a medieval comedyplay presented by the amateur theater group Hullu Hukka, which Jukkais a member of. The Mad King is one of the most popular plays of thetheater group, and has been presented in many medieval fairs after itsinitial performance on February 1998 in Epoo, Finland.Jukka spent a weekend on stage playing the role of the Mad King whenwe were finalizing the 1.2 release.
We keep a complete list of the release names and their explanations inthe Midgard FAQ.
New On DevShed:
Currently Active Forum Topics:
|
