Re: Midgard and Ruby/Scriptor

[email protected] wrote:

> > Midgard used to have Ruby support...
> > http://www.koders.com/ruby/fid0F4C077B555E5E0D1BDE20EE450FB77AD2783D30.aspx
> > http://www.fh-luh.de/~mad/hypermail/1860.html
> >
> > I wonder what would it take to revive this effort to support new Midgard API?
> 
> While this is definitly interesting, I'd recommend focussing on the task 
> getting the "new Midgard API" finished and working... We have enough 
> problems on our hand already (both technical and organizational).

Let me elaborate a bit before we could start endless thread.

Core API isn't changing during the days. 
Basic API which should be used for language bindings:
https://www.midgard-project.org/api-docs/midgard/core/html/group__MgdObject.html
changed once few days ago ( minor changes with functions which return gboolean now).
 And it's not widely used except midgard-php binding so I do not think that neither Your work 
nor any other developer nor midgard-java binding was badly affected by this change.

Ruby binding or even ( probably better ) perl or python should be made much easier than 
PHP bindings. Those languages have much better GObject support than PHP so I personally 
believe that such bindings would help a lot with creating good and stable API.

Midgard-php API is a different matter as this one doesn't change itself from day to day.
I see huge difference between API changes and issues and bugs.

Let's have a look at few examples:

1. Object's constructor ( we talked about yesterday )

Whatever OO rules you would like to use and whatever OO terminology should 
describe your needs , we hit the wall ( IMO ) with such "little" detailed issue like
value returned from constructor.

What is implemented in HEAD is object's constructor which is able return FALSE while 
type of returned value is 'Object'.

It's not clear for me. So in such cases I need *very detailed* discussion about PHP API.
What I would like to focus on  is particular language binding and its possibilities then , instead 
of focusing on OO concepts and its terminologies.

2. midgard_reflection_property

I changed a bit this part of API which now is "optimized" for midgard-php , but breaks some 
GObject binding conventions. And I am still not sure what is the best choice.
If you look at reflection API documented at m-p.org you should notice that it's far from being 
perfect in OO terms. 
Why? Because Zend1 has no real support for such bindings. What is "suitable" for such purpose 
is Zend's resource handler which can handle once created GObject instance. But, I am still afraid 
( let's hope I am wrong ) to use zend resources for such features.

	a) Everyone remember annoying segfault triggered by such ( or similiar ) code:
	
	$arts = mgd_list_topic_articles($id);
	mgd_auth_midgard(...);
	while($arts && $arts->fetch()) .....

	Segfault was always triggered by zend's resources being "everyone uses it , but nobody really 
	knows what's going there". This part of legacy midgard-php still triggers memmory problems 
	and will be *never* fixed.

	b) QB implemented in midgard-php is the only one object type ( in new API ) which uses 
	zend's resources. And as well as old fetchables triggers memory problems.
	Simply create as many QB instances as many memory you want to loose.
	It's not midgard-core or midgard-php binding related.

Another issue related to " getting the "new Midgard API" finished and working " is the fact that there's 
almost 0 threads on dev list about midgard-php binding.  Midgard-php binding is difficult if you think 
about 'what I want from OO language' and 'how binding may be done'. 

I think that we can find some real unresolvable trap using "I expect this to be working stable and good"
instead of "how can we resolve this issue for this particular language".

Piotras