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

Torben Nehmer <[email protected]> wrote:

> 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.

Can you be honest and tell for how long do you use 1.8 and which functionality 
changed much more than you expected? 
 
> 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). 

Can you point directly to this *large undocumented part* ?
As far as I know there are few functions undocumented in core. 
*few* written at the beginning.
*Everything* written within last six months *is* documented.

The reason why we have no core docs on m-p.org is simple.
I didn't know that I can run doxygen from cron.

Probably I also made huge mistake adding reflection and metadata docs before 1.8 stable is out.
Is that correct?

> 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.

Torben , as much as you need *detailed* specs I need *Your* feedback about OO 
issues. Please be more verbose about OO. If OOP could be the same then we 
could use only one language.

Please be detailed. Do not use words like 'interface' ( example ) when you use PHP4 language.
What should I understand from this?

There are few things which can not be done on higher level. 
Like on_update callbak methods etc etc.

Coming back to OO. Yes , we can make more OO in core. 
But  ask yourself : "Does PHP4 supports it?" "Is it doable and reasonable for apache&php&midgard?"
 
> - - QB-APIs, which still produce notices on empty(!) resultsets

Yes, this one is bad and frankly speaking I hardly see "bad query".
Bad Query in midgard means very critical thing which shouldn't be never reported
as error or anything similiar.

> - - QB calls which just fail when you pass them null (at least they don't segfault
>   anymore).

Did I ask about "typecasting" from NULL values?

Or should I made another hack for midcom ( you) ? 
Are you going to blame me @dev ( again ) for such another hack wrote for "faster midcom development" ?

> - - 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.

http://www.midgard-project.org/midcom-permalink-a4e185a08fb2d0e278ef1ba3a739f77e

There is also search available:
http://www.midgard-project.org/search/result.html?type=basic&page=1&submit=Search&query=schema+file
First link with 100% score will be a good start.

> - - 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.

mRFC 0020
http://www.midgard-project.org/midcom-permalink-2483d6bf98302c3e81fdddc4ad91b784

I listen to every developer. I do not need to vote + or -. But if the mRFC is passed I try to 
remember about this.

> - - The neccessity to get_by_(gu)id instead of just using the constructor of the
>   DB class (like in DBA).

Can you point me to this book which says that object's constructor must be "overloaded" with object's identifier? 
Is it OO convention or a must or a midcom design?

Is midgard-perl or midgard-python or midgard-java object forced to use the same constructor 
as designed for midcom?

> - - 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>

1. I read dev list. Every single mail. Did I miss some tragical midgard worldwide server breakdowns?
If some SIG_ABORT happens , why I know nothing about this?
How long community waits for fixes from me? months?

2. We still use legacy code. Many of its part can not be fixed or improved withour full rewrite.

3. I thought this is how development looks like. One broken feature in release X is fixed 
and improved in release Y. 

You already wrote about 1.8 changes so you probably noticed that midgard-schema cli tool 
will make initial schema parsing and what is more will make initial object methods testing. 

> 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.

Elborate please.

Piotras