MidCOM and its further adaption to new Midgard versions - AKA Midgard core quality

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

as you might have noticed, I'm already growing a bit annoyed again about certain
 changes in 1.8 functionality, which seem - to me - not very well
thought-through. I have already complained about this trend more then once, both
in IRC and on this list, without too much of a response except the work did by
Jukka. Therefore I now draw my consequences.

To sum it up for a last time:

Large parts of the Midgard core, *including* the new parts that have been
written within the last 6 months, are undocumented, both in terms of their
specification and their actual API (both on a C level and on their language
bindings). In addition to this, many of the enchantments done are very isolated
pieces of "this could be a good thing here", they don't fit into a (not actually
existing) grand scheme and forced me to create hundreds, if not thousands of
lines of glue code to bring them up to the OO standards I provide to my authors.

Just to name a *few* examples as they come to my mind:

- - QB-APIs, which still produce notices on empty(!) resultsets
- - QB calls which just fail when you pass them null (at least they don't segfault
  anymore).
- - An mgdschema file format, which provides tons of features to you, given you
  can get hold of one of the core guys so that he cen tell you about it.
- - Date handling in the schema, which is unflexible and actually broke full
  backwards compatiblity by deprecating UNIX timestamps replacing them by ISO
  timestamps everywhere (not just on date fields you explicitly declare). My
  recommendation to have more then one date type to handle this was ignored.
- - The neccessity to get_by_(gu)id instead of just using the constructor of the
  DB class (like in DBA).
- - No schema parsing in config-test, essentially shooting down your server in
  case you have an error in your schema when trying to restart. Especially great
  for production environments. <irony> At least we now have an occasional error
  message before a SIG_ABORT here, not just a SIG_SEGFAULT, guess I should be
  grateful.</irony>

The existing documentation (like the MgdSchema or QB API in the Wiki) is - to
say it defensivly) mostly useless, it omits most cavets that are in all those
classes.


I said that I'd draw the consequences:

Hereby I officially cease to support any 1.8 version/feature in the current
MidCOM CVS codebase or any future development thereoff in any part of the core
(/lib/midcom/*), unless:

a) The whole development of the core gets into a more regulated and documented
iterative software development process including full specifications (not like
mRFC 12, more like mRFC 24).

b) The core is completly and verbosly documented in terms of *both* core *and*
language binding (at least PHP) level.


I will no longer put any time into discussing these things, this is
unproductive, time-consuming and frustrating in most cases nowadays. If you want
me to support a feature, show me the *full* specs and docs you have about it so
far, then I'll give you thumbs up or down (with critics of course).

I will not comment 25-line specifications of anything.


Again, I regret that I have to take this drastic measure, but I stand for MidCOM
core quality with my name throughout the community, both private and commercial
(and thus my current primary income).

If the Midgard core cannot keep up to the standards I am trying to establish so
far, I cannot keep up this level of quality I have established so far. Thus I am
 forced to stay with versions that I can safely declare usable for myself.


There will be *no* discussion about this topic. If you do not like my decision,
feel free to find another MidCOM project leader or just fork off your own
branch. But as long as I have the final saying on this, my decision stands.


Live long and Prosper!
Torben Nehmer

- --
Torben Nehmer, Guenzburg, Bavaria, Germany
http://www.nathan-syntronics.de, mailto:[email protected]
PGP Public Key: https://www.link-m.de/pgp/t.nehmer.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD6esCJPh4Kn6d5FYRAl0qAKCHq6jijwL0As1uWVtcKH3VRkDhpgCdET+f
9kM/CTlJuQfVN6nCZ+PAt+M=
=eHl3
-----END PGP SIGNATURE-----