Midgard and Ruby/Scriptor
-
Henri Bergius
Midgard and Ruby/Scriptor
Thu January 01 1970 00:00:00 UTCGreetings!
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?/Bergie
Henri Bergius Consultant Partner, Nemein henri.bergius@nemein.com
Midgard CMS www.midgard-project.org
To unsubscribe, e-mail: dev-unsubscribe@midgard-project.org For additional commands, e-mail: dev-help@midgard-project.org -
-
Re: Midgard and Ruby/Scriptor
Thu January 01 1970 00:00:00 UTC-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
- --- On 01.03.06 22:58 (+0200) Henri Bergius 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).
Live long and prosper! Torben Nehmer
Torben Nehmer, Guenzburg, Bavaria, Germany http://www.nathan-syntronics.de, mailto:torben@nehmer.net PGP Public Key: https://www.link-m.de/pgp/t.nehmer.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76iD8DBQFEBgubJPh4Kn6d5FYRAl5QAJ4s1vfUcyCMhvh+aBxt+9o9ERJiqwCfaMZx UJtnUyEcy7QsG8/gyo+e62Y= =szJT -----END PGP SIGNATURE-----
To unsubscribe, e-mail: dev-unsubscribe@midgard-project.org For additional commands, e-mail: dev-help@midgard-project.org -
Re: Midgard and Ruby/Scriptor
Thu January 01 1970 00:00:00 UTCOn Mar 1, 2006, at 23:01, torben@nehmer.net wrote:
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).Agreed, we need to clean up the API and get solid PHP and Java
bindings before expanding to other areas. I hope this means around 1.9.However, I just was reminded of the Ruby stuff and wanted to bring it
up...Torben Nehmer
/Bergie
Henri Bergius Consultant Partner, Nemein henri.bergius@nemein.com
Midgard CMS www.midgard-project.org
To unsubscribe, e-mail: dev-unsubscribe@midgard-project.org For additional commands, e-mail: dev-help@midgard-project.org -
-
Re: Midgard and Ruby/Scriptor
Thu January 01 1970 00:00:00 UTCtorben@nehmer.net 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:
- 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.
- 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
To unsubscribe, e-mail: dev-unsubscribe@midgard-project.org For additional commands, e-mail: dev-help@midgard-project.org
