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

Torben Nehmer <[email protected]> wrote:

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

Please ( if only possible ) write to log my #midgard activity.
Remind me later if you were asking about legacy stuff or new one.
 
> > 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?

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

which means?
 
> > 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.

Yes you can. Just keep in mind two things:

1. Focus on language you work with 
2. We can not make some things before some other ( planned for a future are made )
 
> > 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.

Again. How should I know what you meant?
 
> 
> > 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.

This is not a hack. This is the way how you designed midcom.
Hack is when update method behaves different way on midgard-php and midgard-java levels
while both at last invoke the same core's update method.
 
> >> - - 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.

I ignore anything which recommend to make something from anything.

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

Because it was last evenning when you ask me about another hack for midgard-php's is_guid?
You mentioned about discipline. Is it correct habit to pass object to function which requires
string and be happy when no warning is being produced?
 
I could write some spec within this 30 minutes when I had to waste to make this.

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

Torben , do you see any difference between *undocumented* and *missed in docs* ? 
 
> 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.)

You are talking about something which is not schema related and can not be documented.
What author field?
 
> 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.

metadata is written according to discussions @dev.

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

$article = new midgard_article();
$article->get_by_path("path/to/article"); /* returns article with id=12345 */
 
$article = new midgard_article();
$article->topic = $id;
$article->name = "index";
$article->get();  /* returns article with id 54321 */

BTW, adding getstatic alias will make this almost M-L ready.

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

Should I notice or find some unread ( by me ) feature request at midgard.tigris ?
 
> > 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...

Yes. Add non existing directory path as log path to any virtual host, and apache won't start up too.
I think this is typical. 
 
> > 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.

Yes, I have to. We can not make proper error mechanism before midgard connection 
handler is rewritten. Midgard connection handler should be rewritten when we implement
libgda support. Libgda support is planned for 1.9. 

> > 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.
 
Yes , you are right. midgard-schema cli tool is undocumented.
First undocumented thing from 1.8 branch ( not exisiting yet ).

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

I think you talk about different thing than bad path for schema file.
 
> 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.

Generally midgard is good piece of software. But if you look at details it sometimes can be bad.
Generally I agree with you. But I think we miss some details.
Generally I think I wrote docs. But You think I missed details.

Piotras