Piotras' blog: Archive

Midgard2 - flexibility rocks

Posted on 2007-01-11 23:47:33 UTC.

There's much work done ( and much to be done still! ) to get clean and clear Midgard2. However I am quite impressed when I think how things look like now.

Core is just yet "another" library and proved to be quite usefull for:
language bindings, GTK applications , Apache modules or command line applications.
It's just the way how library should be built. Ah! I am very glad I can use midgard-core with libgda ( website seems to be refactored now ). At last I can forget about MySQL dependencies and its API.
As an addition, I also added openssl support today.

Apache module is just yet "another" Apache module. Unlike Midgard1 module, this one is "environment and language unaware". And it means that this module can be used with any language like perl, java or python.

And...this module forced me to create that "trick" in core , so you can initialize midgard library in GType system unaware application and use its power with forked GType aware child.

Today, new refactored midgard-apache module finds midgard hosts ( those prefixed too ) very well. Correctly parses uri to get midgard pages and nicely serves images attached to pages. This is very nice to notice correct 200, 404 or 403 :)

PHP extension is just yet "another" PHP extension. You can use it with php-cli scripts or just build websites.
( with MidCOM you do it quickly :)

Repligard functionality ( known from Midgard1 ) is just "yet another feature" of midgard-core.

I must say. It looks good :)

And what happens with stable 1.8 branch? I fixed few important issues related to midgard_collector, so we should have new 1.8.2 released very soon.

Midgard sitegroups

Posted on 2007-01-17 13:18:06 UTC.

Midgard sitegroups concept is well known since Midgard 1.4 release.
This excellent feature has beed added to Midgard library almost seven years ago but till today no one clarified few important issues. I have been talking with Bergie and Rambo about this and we decided to clarify and fix this once and for all.
However you may expect some issues raised in new Midgard releases, you should not to be worry about them as it will affect only Sitegroup 0 Administrator , well known as Root User.

BTW, I updated midgard sitegroup concept docs and we should definitely use this convention to name Midgard persons:

• Root user ( Sitegroup 0 user )
• Administrator ( a person who is an administrator within sitegroups X )
• User ( any sitegroup X user )

Sitegroup issues which now are clarified:

• You can change object's sitegroup only when you are in anonymous mode or you are being logged in as Root user. And you can change sitegroup only ( and only ) when objecty is not yet created. In Midgard 1.8 series any attempt to change sitegroup property is silently ignored ( due to PHP&ZEND1 ).In newest Midgard , any attempt to change object's sitegroup will trigger unconditional warning.
  

• Administrator and User always manage objects in sitegroup context.

• Root user always delete, update or create object in sitegroup context. In this case it means that we use object's sitegroup property to determine its sitegroup instead sitegroup of current application. Unlike Midgard1 concept ,it means that being logged as Root user you always update or delete object with particular guid and particular sitegroup.
  

• Root user can query objects ( using Query Builder ) and get many objects identified by the same guid but within different sitegroups.

The issues I know for now are:

• how to handle midgard_object_class::get_object_by_guid($guid) static method in a safe way? Probably we should add second optional argument ( sitegroup identifier ) valid only for Root user.
  

• how to handle midgard_replicator::export_by_guid($guid) static method? The solution seems to be tha same as this proposed for get_object_by_guid.
  

For now , midgard-core tries to be as smart as possible and if one of these methods returns more than one record ( for Root user ) MGD_ERR_SITEGROUP_VIOLATION ( Resource link crosses sitegroup borders ) error is unconditionally thrown.

And as we work on new replication framework , we should be able ( very soon ) to replicate the same object between many sitegroups in one database.

Setting up Maemo scratchbox

Posted on 2007-01-20 15:20:08 UTC.

It's worth mentioning. When you try to setup scratchbox for maemo you probably ended up with googling and looking for this :

Xephyr cannot open host display. Is DISPLAY set?

I am almost sure that you use gnome, so enable TCP connections in GDM setup.

Unfortunatelly I resolved this weird issue while my user's scratchbox account started to acting up so obviously I need to reinstall scratchbox.