Hi all,
At first I must say I'm sorry I haven't been able to spend as much time
with Midgard and the list as I would have wanted lately. The reason for
my silence is that I'm currently working some 10-12 hours a day and that
leaves little time for Midgard. The situation probably won't change much
before February. :( In addition to coding, I get to manage most of the
basic administration and have time to answer to some of the list
messages, but that's about it. I'm thankful to Emile and all the other
people who are actively participating in this project. You're doing a
great job!
Then to business. I've been working with the Midgard 2.0 rewrite for
some time now and I believe we'll have a beta version available by
Christmas. Here's a listing of the most important new features together
with a percentage estimate of the work that has already been done.
Packaging (50%)
It'll be possible to export parts of the Midgard database to XML files
that can be transferred and imported to other Midgard databases.
Replication (20%)
The packaging format will be used to support a simple replication
scheme. There will be a simple utility program that checks the package
files and writes any new content to the database. The system won't be
able to handle conflicts and won't try to merge the records. Instead it
just uses the latest of the available records. It will also be unable to
replicate record removals. (A history table could be added to provide
intelligent conflict management and deletion behaviour.)
Unique IDs (70%)
Inter-database transfers require truly unique record IDs. Records from
different databases must not collide when databases are combined. We're
going to have 120-bit ID strings that will be represented by 20 base64
characters. The IDs will be constructed from a 32 bit timestamp, a 32
bit random number, a 16 bit process id, a 32 bit hostid (IP address, or
similar, configurable), and a 8 bit database id (generated by a name
hash). Compatibility with old ID numbers will be maintained, but they
might cause replication conflicts.
Database independency (90%)
Midgard 2.0 uses ODBC to access the underlying database. The record
fields have been changed for better standard compliancy. Only simple and
standard ODBC datatypes are used. Native database interfaces could be
added if performance is an issue.
Modular architecture (90%)
The different record types of Midgard have now been abstracted as
modules in the Midgard library. New modules could easily be added
without disturbing the rest of the system. This way it'll be easy to
extend Midgard's capabilities for specialized data storage. For example
someone might want to port the Bugzilla database format to Midgard, and
be then able to use a native Midgard bug database!
Dynamic record types (20%)
A special kind of record type module will be added in Midgard 2. It
won't have any special field structure. Instead it'll allow dynamic
creation of new fields to individual records. There will be a special
table that links new fields (name,type,value) to existing records.
You'll then be able to do a mgd_get_extra_fields($id) or
mgd_set_extra_field($id, $name, $value) to get or set the dynamic
fields. Accessing these fields won't be as fast and easy as with builtin
fields, but they will allow custom extensions easily and portably.
PAM authentication (90%)
Midgard 2 uses the PAM architecture in addition to the normal Midgard
authentication. The HTTP authentication is mapped to PAM API calls that
allow administrators to plug in all sorts of authentication modules. For
example the user information from /etc/passwd, Windows domains, LDAP or
other sources could be used.
Access control (10%)
The access control mechanism will be rewritten to support generic ACLs
in addition to the current access control options available in Midgard.
Yours,
Jukka
--
This is The Midgard Project's mailing list. For more information,
please visit the project's web site at http://www.midgard-project.org
To unsubscribe the list, send an empty email message to address
[EMAIL PROTECTED]
