Midgard Weekly Summary for August 24, 2000 (#44)
Aug 24, 2000, 22:33 (0 Talkback[s])
(Other stories by Ken Pooley)
Re-Imagining Linux Platforms to Meet the Needs of Cloud Service Providers
Date: Thu, 24 Aug 2000 16:35:07 -0500
From: Ken Pooley firstname.lastname@example.org
Subject: MWS for 24th of Aug, 2000 (#44)
Another week, another MWS! Below is an interview with Ron Parker
who is working hard on the documentation efforts for Midgard. There
is also the start to a discussion for the whole community on how
best to get across what Midgard is and what it does. The next few
weeks should bring the continued final work on Midgard 1.4 as well
as much more concrete discussion about Midgard2.0 and what it will
Stable: 1.2.5 'Mad King'
Oracle: 1.2.5 Oracle 8i
An Interview with Ron Parker about Documentation and Midgard
Ron Parker is a writer and music expert from Wisconsin, USA.
While quietly writing the MWS one day he was tapped to travel to
Paris, a long way from Wisconsin, to work on the efforts to update
and complete the documentation for Midgard versions both old and
new. Documentation has been an ongoing process for the Midgard
community and the concentrated efforts that Ron and a few others
have brought to the project will make a huge difference in the long
It seems like there are a lot of efforts to work on the
documentation for Midgard. What is the state of the documentation
at this point? How much of what you are doing expands on what had
been done before and how much is being done to anticipate 2.0 as it
is in the works?
We don't have adequate documentation. I've compared our
documentation to Zope's and modeled a strategy to avoid producing
an indecipherable Hodge-podge like they have. The primary
difference between them and us is they've got a bigger mess than we
do. I don't mind criticizing Zope because I've recently discovered
that they've got a solution. I think things are looking good in the
Zope documentation camp. They've got a contract with O'Reilly and
will replace the on-line documentation with the material that's
being written and edited for the book.
I'm really saying, good for them and take note Midgard
developers because we must have documentation that's as good or
better than what they're now producing. If our product isn't as
good as there's, the market will choose them over us even when if
our product is more suited to more address their challenge.
Remember Midgard is a Content Publishing tool while Zope is an
Application Server. They're different animals. Application servers
are optimized for transactions and solving business logic. Content
management is about serving data.
Anyway, back to your question; almost everything we're doing now
is from scratch. We're producing a combination of marketing and
technical white papers. The work we're doing now is designed to
accurately define Midgard for what it really is. The first document
I wrote says, "Application Server." In fact, Midgard isn't an
application server. Midgard 1.4 is a Content Publishing Tool. When
Aurora, a Paris, France Open Source start-up, first contacted me, I
was under the impression that they and I were interested in
producing User documentation for 1.4. My boss, Jean-Philippe
Brunnon, introduced a set of challenges which have changed the
focus of the documentation effort.
The first challenge focuses the effort of the entire project on
developing Midgard 2.0. This branch will be a complete rewrite. If
we focus our attention full-time on 1.4, we'll release the
documentation at the time that 2.0 is available. There's no better
way to assess this strategy than to say it would be stupid to spend
time writing extensive documentation for 1.4.
Midgard 2.0 is being designed as a Content Management system.
Bruno Abitbol, Aurora employee and Midgard developer, has
implemented the Midgard database in LDAP and is testing ease of
feature implementation. I've seen his SiteGroups solution and it's
a significant improvement over the current Midgard layer strategy.
This improvement translates to ease of implementation at the user
level. Of course, we've gotta run performance tests.
My personal aspirations are to produce a document for
programmers and end users that third party publishers will knife
fight over. The Aurora management and I have begun discussing a
contract and strategy for producing Open Source Content Management
(Midgard 2.0). Aurora is interested in co-publishing in order share
financial investment and accelerate the production rate. The
impetus is to marry the name Aurora with Midgard. Coming from the
Midgard camp, I respect their investment and am beginning to learn
about their interest. Developing a relationship has been a
challenge but I am hopeful. I see good things and have even learned
a couple French words.
How big is the core group of authors? Are they connected
geographically or just electronically. How hard is it to get all of
the parts to work together?
Armand Verstappen has been contracted by Aurora to produce the
function reference documentation. Of course the core developers
offer technical related feedback when asked and if they've got
time. Simon Kerr has worked with Patrick Duplouy to create a the
first draft documents for the 1.4 technical white papers. Cedric
Musso has contributed mostly by managing and redesigning our
docbook strategy. Many people worked to produce the material that's
in the on-line manual. The current effort is not working with that
material. I focus my attention on the coffee pot and my depleted
cache of cigars.
1.2.5 and 1.4 are still basically based on the first versions of
Midgard. How much more difficult, or less difficult, is it to
document 1.4 when it is a transition from the earlier versions,
which you may not had as much to do with, to an anticipated version
that you are involved with.
I'm a writer who started using Midgard so I could be exposed to
people that know what they're doing. I can't read mod_midgard and
write a document that describes what the damned thing does. From my
perspective, the challenge isn't presented by differences between
1.2 and 1.4. The real problem is in the absence of Requirements
documentation that describe why something was implemented and how a
relative piece of code solves the problem. This is the material
that's needed to produce documentation.
I recently stole a book that was purchased for Alexander Bokovoy
titled Practical Software Requirements, Manning, it'll be a cold
day in a place that's consistently hot before I forward this book
to its rightful owner. I desperately need to understand Software
Engineering and this book is helping. My challenge is to understand
the ideal process for producing software and documentation,
formulate a strategy that's realistic for Midgard, call the cow
into the barn and extract the milk. You can make all kinds of good
stuff with milk.
Jean-Philippe Brunnon, Aurora project manager, has just handed
me a first version of the Midgard 2.0 White Paper. No code has been
written for 2.0 and there's some documentation. This white paper
will tell our user and developer communities what to expect. This
allows input during the design phase because these documents will
live in CVS.
Do you have a sense yet for what 2.0 will be like from an
administrators point of view?
I believe load balancing, redundancy, data syncing, user and access
management will move Midgard administrators into an entirely
different level of problem solving.
We're developing a 2.0 Content Management solution that is Open
Source from the backend to the webserver. It'll be scalable so
developers who wish to implement commercial solutions like an
Oracle RDBMS will be able to. J-P's 2.0 White Paper lists ascending
compatibility with 1.4 as the first requirement of 2.0. Also,
comrade Bokovoy has met a developer at a database conference in
Minsk, Belarus who has implemented a MySQL to LDAP interface.
Jean-Philippe is looking at that code to see how the relational
tables are mapped to the LDAP tree structures. This work is
interesting for the Midgard efforts.
Midgard 2.0 looks like a serious problem solver. From my
perspective it looks like Aspirin on steroids.
Jean-Philippe Brunon at Aurora opens discussion on promoting
Jean-Philippe Brunon, of Aurora, has opened an important
discussion about the means by which we can, essentially, market
Midgard. While the benefit for Aurora may be somewhat evident, we
as a community also get a great deal from the success of Midgard;
better software, more development resources and someone on the
other end of that desperate 2 AM email when things just won't work.
Jean-Philippe had a few salient points as he walked through the
means by which people find out about Midgard. From finding Midgard,
to finding out about Midgard, to finally installing and
implementing Midgard. As Jean-Philippe pointed out, the number of
increasingly high hurdles and enduser faces at each stage along the
way is daunting at best. We are all involved making those hurdles
less problematic but it would be worth while to look at the way we
market our efforts. Last week I called for those using Midgard for
public sites to submit URLs to the Midgard-Project.org website for
inclusion on the list of sites using Midgard. Other suggestions
would be welcomed as well as feed-back as the development cycle for
1.4 and 2.0 continues. Jean-Philippe's e-mail, with the follow-up,
can be found at:
Midgard is a freely-available Web application development and
publishing platform based on the popular PHP scripting language. It
is an Open Source development project, giving you the freedom to
create your solutions in an open environment. Midgard is the tool
for creating, modifying and maintaining dynamic database-enabled
The Midgard Weekly Summary is a newsletter for the Midgard user
and developer community.
The MWS is currently being distributed in following mediums:
-The Midgard Project's Web site
-Linux Weekly News
-Linux Developer's Network
-Midgard mailing list
If you would like to release it elsewhere, please contact Henri
Previous issues of Midgard Weekly Summary can be found archived
at the Midgard web site.