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

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

Hi,

- --Piotras wrote on 2006-02-08 15:27:
>> 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.

Which is why I always have to ask you or read the source. Yes, thanks.


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

You're kidding now are you?


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

q.e.d.


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

I have been trying to give you my feedback about the PHP application side for
months now, as precicly as ever possible. (Like with our last discussion about
GUIDs). Either you don't understand me, for whatever reason, or I'm not detailed
enough. But honestly, I don't know if I can be even more precise in the
requirements I formulate.


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

Even PHP4 needs an Application Programming *Interface* know as API and often
abbreviated as "interface".

Of course I didn't mean the "interface" language construct known by Java & co.
that's basically an simplified abstract base class in the context given.


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

Yep, where we are back to the workarounds and hacks I have hooked into MidCOM.


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

Using Code-by-contract? Sure. There are many OO things you can do with PHP 4
even if the corresponding language constructs are not *enforced* by the
compiler. This is not compfortable, but it does work and above all it does not
prevent us from using the power of OO even in PHP4.

At least in MidCOM it works well. Of course, this requires discipline on the
side of the programmers...


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

Yep, you got (and ultimately ignored) my recommendations.


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

Why does everybody insists on making hacks for others? (This is another problem
of the entire project, this "hacking away" mentality.)


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

Which is good (didn't notice that it has been updated) but still incomplete.

Correct me if I'm wrong but table names must be equal to type names *at least*
in Midgard 1.7 otherwise you could get weird problems in various places. At
least I had to rename my tables/types at your direction.

In addition, there is *no* reference (from that page at least, haven't searched
for it) to a documentation how a table for a type has to look like. Missing
author fields and the like are the least of these problems. (Or a change log
about this topic to aid us developers.)




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

Yep, which is the reason for all created/updated timestamps now being ISO
Timestamp DBA hast to back-convert to UNIX Timestamps for all code to still work.

I never said "drop all UNIX Timestamps [that] unconditionally". I just wanted to
have ISO timestamps wherever fully qualified dates/times are needed (for
birthdays etc.).

The brand-new Metadata system is different here of course. As a new system you
can establish new conventions there.


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

*args*. That is another one of those arguments that I could reverse exactly.

Of course it is nowhere written that *every* constructor used in DB layers
*must* be overloaded such-and-such.

But it is a) convenient and actually (believe me or not) common use in many
libraries out there. The power of overloaded constructors is just for these cases.

Can you honestly tell me that this

  $article = new midgard_article();
  $article->get_by_id(17);

is better then

  $article = new midgard_article(17);

*Especially* since the constructor of DBA takes both ID *and* GUID transparently?


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

If you can honestly tell me that the unoverloaded constructor is better in other
languages, we can argue.

But this is a matter of language bindings. Again you're missing the grand scope.


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

Simple case. Make an include in the schema.xml whose file does not exist. 1.7
Apache does not start up. You surly tested this simple case...


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

Don't complain with me about legacy code. MidCOM is full of it. Which is why 1.4
MidCOMs still run under MidCOM 2.5.


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

Which is not part of 1.7.3 or earlier version just to say. Where is this tool
documented, it is surly not referenced from the "MgdSchema file properties" or
"MgdSchema file" articles.

And, btw. saying that there is a "command line tool" which can check the config
is a poor excuse for missing error handling in apache startup.


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

I did above.


I hope that this clarifies a few points. Again I'm talking about the general
situation, not about details of the examples I brought up to give a better
understanding about the issues.


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

iD8DBQFD6gfWJPh4Kn6d5FYRAlMWAJsGTm1bOfW+ZkjWD5Y1ztrqonaVNwCeOoWy
MF2KGK3VJfCfwjKlpa4g1SU=
=SIzo
-----END PGP SIGNATURE-----