How about project Ragnaland?

1 2 next

Henri Bergius

How about project Ragnaland?
Thu December 04 2008 14:10:26 UTC
Hi, all

Just an idea: with Ragnaroek .3 we have put a lot of effort into
removing legacy API usage from MidCOM and components.

In March we will release Vinland, which is based on the legacy-free
Midgard2 code. But with it, the MidCOM3 that we will release will
focus on being a killer MVC framework, not a CMS.

So, how about ensuring Ragnaroek MidCOM really uses *no* legacy API,
and starting to experiment with getting it to run on Vinland?

Benefits:
* Ragnaroek MidCOM will be fully free of legacy API, making the code cleaner
* After Vinland is released, even Ragnaroek-based clients can be
upgraded to it, reducing the need to support legacy Midgard code
* This would make it possible to run Ragnaroek MidCOM on different
databases and platforms
* Ragnaroek MidCOM and MidCOM3 can run side-by-side on same Midgard installation

Effort needed:
* Clean all legacy API usage from Ragnaroek
* Backport the Midgard style engine implementation from MidCOM3 to
Ragnaroek MidCOM
* Create a MidgardRootFile for bootstrapping Ragnaroek MidCOM on Vinland

How would this sound?

--
Henri Bergius
Motorcycle Adventures and Free Software
http://bergie.iki.fi/

Skype: henribergius
Jabber: henri.bergius@gmail.com
Jaiku: http://bergie.jaiku.com/
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev
- Reply
Henri Bergius

Re: How about project Ragnaland?
Thu December 04 2008 15:07:04 UTC
Hi,

Related to this, I dug around Ragnaroek MidCOM to see what legacy APIs are actually used there. Here is the list:

Error handling API:

These can be replaced with the midgard_connection error management methods, see http://trac.midgard-project.org/ticket/610
- mgd_errstr: 593 instances
- mgd_errno: 95 instances
- mgd_set_errno: 66 instances
Style engine API:

Can be implemented as part of the PHP-based style engine, Vinland has no cache by itself. Functions used in Ragnaroek:
- mgd_clear_cache: 2 instances (method not in Ragnaroek! Should probably call mgd_cache_invalidate instead)
- mgd_cache_invalidate: 18 instances
- mgd_is_element_loaded: 11 instances
- mgd_preparse: 6 instances
- mgd_template: 1 instance
- mgd_format: 10 instances
- mgd_register_filter: 4 instances
Authentication API:
- mgd_auth_midgard: 1 instance, can be replaced with midgard_user::auth()
- mgd_update_password: 1 instance, should use $person->update(), method not in Ragnaroek!
- mgd_update_password_plain: 1 instance, should use $person->update(), method not in Ragnaroek!
Midgard connection API:
- mgd_get_midgard: 8 instances, probably unnecessary with modern Midgard altogether
- mgd_get_default_lang: 4 instances, no equivalent in modern API?
- mgd_set_default_lang: 3 instances, no equivalent in modern API?
- mgd_set_lang: 14 instances, can be replaced by $_MIDGARD_CONNECTION->set_lang
- mgd_config_init: 5 instances, can be replaced by midgard_config API
- mgd_debug_start: 26 instances, can be replaced by $_MIDGARD_CONNECTION->set_debuglevel
- mgd_debug_stop: 26 instances, can be replaced by $_MIDGARD_CONNECTION->set_debuglevel
Sitegroup API:
- mgd_get_sitegroup: 10 instances, how does the new SG API work?
- mgd_get_sitegroup_size: 2 instances, how does the new SG API work?
Blob API:
- mgd_get_attachment: 3 instances, must be replaced by DBA attachment API, method not in Ragnaroek!
- mgd_stat_attachment: 4 instances, how does this work in the new blob API?
- mgd_delete_attachment: 2 instances, must be replaced by DBA attachment API, method not in Ragnaroek!
Other:
- mgd_is_guid: 60 instances, we need a new API to replace this
- mgd_get_object_by_guid: 2 instances, must be replaced with midgard_object_class::get_object_by_guid(), method not in Ragnaroek!
- mgd_version: 19 instances, we need a new API to replace this
- mgd_get_person: 3 instances, must be replaced by DBA person API, method not in Ragnaroek!
- mgd_list_groups: 1 instance, must be replaced by DBA group API, method not in Ragnaroek!
- mgd_list_persons: 1 instance, must be replaced by DBA group API, method not in Ragnaroek!
As you can see, some methods must be implemented in the new API still before we can go legacy-free. But most is just search-and-replace work :-)

The important thing is to ensure that all these APIs work the same way in Vinland and Ragnaroek.

/Bergie
- Reply
Henri Bergius

Re: How about project Ragnaland?
Thu December 04 2008 15:58:41 UTC

Related to this, I dug around Ragnaroek MidCOM to see what legacy APIs are actually used there. Here is the list

Some of those have already been cleaned up, see:

http://trac.midgard-project.org/ticket/611

/Bergie
- Reply
Piotr Pokora

Re: [midgard-dev] How about project Ragnaland?
Thu December 04 2008 17:16:24 UTC
Henri Bergius writes:
> Hi, all

Hi!

> Benefits:
> * Ragnaroek MidCOM will be fully free of legacy API, making the code cleaner
> * After Vinland is released, even Ragnaroek-based clients can be
> upgraded to it, reducing the need to support legacy Midgard code

This is most important IMO. Ragnaroek won't be sites' development dead end.

> * This would make it possible to run Ragnaroek MidCOM on different
> databases and platforms
> * Ragnaroek MidCOM and MidCOM3 can run side-by-side on same Midgard installation
>
> Effort needed:
> * Clean all legacy API usage from Ragnaroek
> * Backport the Midgard style engine implementation from MidCOM3 to
> Ragnaroek MidCOM
> * Create a MidgardRootFile for bootstrapping Ragnaroek MidCOM on Vinland
>
> How would this sound?

I think idea is very cool. But of course, one condition - API can not be
changed.

+1 from me for idea.

Piotras
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev
- Reply
Piotr Pokora

Re: [midgard-dev] How about project Ragnaland?
Thu December 04 2008 17:19:15 UTC
Henri Bergius writes:
> Hi, all

Hi!

> Benefits:
> * Ragnaroek MidCOM will be fully free of legacy API, making the code cleaner
> * After Vinland is released, even Ragnaroek-based clients can be
> upgraded to it, reducing the need to support legacy Midgard code

This is most important IMO. Ragnaroek won't be sites' development dead end.

> * This would make it possible to run Ragnaroek MidCOM on different
> databases and platforms
> * Ragnaroek MidCOM and MidCOM3 can run side-by-side on same Midgard installation
>
> Effort needed:
> * Clean all legacy API usage from Ragnaroek
> * Backport the Midgard style engine implementation from MidCOM3 to
> Ragnaroek MidCOM
> * Create a MidgardRootFile for bootstrapping Ragnaroek MidCOM on Vinland
>
> How would this sound?

I think idea is very cool. But of course, one condition - API can not be
changed.

+1 from me for idea.

Piotras

_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev
- Reply
Piotr Pokora

Re: [midgard-dev] How about project Ragnaland?
Thu December 04 2008 18:10:55 UTC
Henri Bergius writes:
> Hi,

Hi!

> Style engine API:
>
> Can be implemented as part of the PHP-based style engine, Vinland has no cache by itself. Functions used in Ragnaroek:
>
> * mgd_clear_cache: 2 instances (method not in Ragnaroek! Should probably call mgd_cache_invalidate instead)

mgd_clear_cache is midcom's function.

> Authentication API:
>
> * mgd_update_password: 1 instance, should use $person->update(), method not in Ragnaroek!
> * mgd_update_password_plain: 1 instance, should use $person->update(), method not in Ragnaroek!

Can be replaced with midgard_user's password method.
I'll update docs ASAP.
The one in vinland is fully backward compatible.

> Midgard connection API:
>
> * mgd_get_midgard: 8 instances, probably unnecessary with modern Midgard altogether

I think we can drop its usage in favour of $_MIDGARD.

> * mgd_get_default_lang: 4 instances, no equivalent in modern API?
> * mgd_set_default_lang: 3 instances, no equivalent in modern API?

Probably not ported from vinland. Should we have it available in .3 or
in .4?

> Sitegroup API:
>
> * mgd_get_sitegroup: 10 instances, how does the new SG API work?

Undocumented. But may be replaced with midgard_sitegroup API which is
used in datagard anyway.

> * mgd_get_sitegroup_size: 2 instances, how does the new SG API work?

Ooops. Completely forgot about this.

> Blob API:
>
> * mgd_get_attachment: 3 instances, must be replaced by DBA attachment API, method not in Ragnaroek!

Replace with MgdSchema midgard_attachment.

> * mgd_stat_attachment: 4 instances, how does this work in the new blob API?

I do not think we need this in core API.
Simple PHP's fstat function will be perfect replacement.

> * mgd_delete_attachment: 2 instances, must be replaced by DBA attachment API, method not in Ragnaroek!

MgdSchema midgard_attachemnt and midgard_blob API.
http://www.midgard-project.org/documentation/php_midgard_blob_method_remove_file

> * mgd_is_guid: 60 instances, we need a new API to replace this

Should we have some 'midgard' class here?

midgard::is_guid()
midgard::version()

or maybe some specific one?

> * mgd_get_object_by_guid: 2 instances, must be replaced with midgard_object_class::get_object_by_guid(), method not in Ragnaroek!

midgard_object_class::get_object_by_guid() is in Ragnaroek.

Piotras
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev
- Reply
Henri Bergius

Re: [midgard-dev] How about project Ragnaland?
Thu December 04 2008 18:55:07 UTC
Hi,

On Thu, Dec 4, 2008 at 8:10 PM, Piotr Pokora <piotrek.pokora@gmail.com> wrote:
> mgd_clear_cache is midcom's function.

No, I think it is simply a mistake. It is used only in build/importStyle.php

>> * mgd_update_password: 1 instance, should use $person->update(), method not in Ragnaroek!
>> * mgd_update_password_plain: 1 instance, should use $person->update(), method not in Ragnaroek!
>
> Can be replaced with midgard_user's password method.
> I'll update docs ASAP.
> The one in vinland is fully backward compatible.

Cool. Anyway, they were in DM1 "account" datatype which I just removed.

>> * mgd_get_midgard: 8 instances, probably unnecessary with modern Midgard altogether
>
> I think we can drop its usage in favour of $_MIDGARD.

Agreed.

>> * mgd_get_default_lang: 4 instances, no equivalent in modern API?
>> * mgd_set_default_lang: 3 instances, no equivalent in modern API?
> Probably not ported from vinland. Should we have it available in .3 or
> in .4?

Well, depends when we want to be legacy-free :-)

>> * mgd_get_sitegroup: 10 instances, how does the new SG API work?
> Undocumented. But may be replaced with midgard_sitegroup API which is
> used in datagard anyway.

Example?

>> * mgd_get_sitegroup_size: 2 instances, how does the new SG API work?
> Ooops. Completely forgot about this.

:-)

Does the modern API support quota in any way?

>> * mgd_get_attachment: 3 instances, must be replaced by DBA attachment API, method not in Ragnaroek!
> Replace with MgdSchema midgard_attachment.

Yes, fixed. It was only in DM1 and o.o.documents anyway.

>> * mgd_stat_attachment: 4 instances, how does this work in the new blob API?
> I do not think we need this in core API.
> Simple PHP's fstat function will be perfect replacement.

Ok, done, committing soon.

>> * mgd_delete_attachment: 2 instances, must be replaced by DBA attachment API, method not in Ragnaroek!

Removed from SVN.

>> * mgd_is_guid: 60 instances, we need a new API to replace this
>
> Should we have some 'midgard' class here?
>
> midgard::is_guid()
> midgard::version()

That is one possibility. I still feel that
midgard_object_class::is_guid() would feel more natural, as we already
have midgard_object_class::get_object_by_guid()

As for midgard::version(), this could simply be $_MIDGARD['version'].

> or maybe some specific one?
>
>> * mgd_get_object_by_guid: 2 instances, must be replaced with midgard_object_class::get_object_by_guid(), method not in Ragnaroek!
>
> midgard_object_class::get_object_by_guid() is in Ragnaroek.

Yep, fixed in SVN.

We discussed the whole idea a bit with jval on IRC, and I think that
as soon as we have modern API equivalents for these in Ragnaroek, they
can be removed from there.

Then we can supply a PHP-level fallback that provides them in case
they're used in styles or something.

> Piotras

/Bergie

--
Henri Bergius
Motorcycle Adventures and Free Software
http://bergie.iki.fi/

Skype: henribergius
Jabber: henri.bergius@gmail.com
Jaiku: http://bergie.jaiku.com/
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev
- Reply
Piotr Pokora

Re: [midgard-dev] How about project Ragnaland?
Thu December 04 2008 19:33:07 UTC
Henri Bergius writes:
> Hi,

Hi!

>>> * mgd_update_password: 1 instance, should use $person->update(), method not in Ragnaroek!
>>> * mgd_update_password_plain: 1 instance, should use $person->update(), method not in Ragnaroek!
>> Can be replaced with midgard_user's password method.
>> I'll update docs ASAP.
>> The one in vinland is fully backward compatible.
>
> Cool. Anyway, they were in DM1 "account" datatype which I just removed.

The purpose of account is to separate user's login and password from
person's data.
I think there should be some support for such type. At least password
shouldn't be set when person's records gets updated.

>>> * mgd_get_sitegroup: 10 instances, how does the new SG API work?
>> Undocumented. But may be replaced with midgard_sitegroup API which is
>> used in datagard anyway.
>
> Example?

$sg = new midgard_sitegroup($name);
Now I realized that id to name translation is needed for higher level.
It exists in core, should be easy to add to bindings.

Well... also depends what you need sitegroup record for.

>>> * mgd_get_sitegroup_size: 2 instances, how does the new SG API work?
>> Ooops. Completely forgot about this.
>
> :-)
>
> Does the modern API support quota in any way?

Sure. We have size computed in metadata.
And quota is managed by midgard_quota class defined in mgdschema.
I just forgot about this one function which computes sitegroup size.

>> Should we have some 'midgard' class here?
>>
>> midgard::is_guid()
>> midgard::version()
>
> That is one possibility. I still feel that
> midgard_object_class::is_guid() would feel more natural, as we already
> have midgard_object_class::get_object_by_guid()

midgard_object_class is sort of reflection class for midgard_object.
mgd_is_guid is generic routine.

> As for midgard::version(), this could simply be $_MIDGARD['version'].

I think mgd_version or midgard_version function is still better than
array's element which can be changed anywhere by anyone.

In core midgard_is_guid and midgard_version are only routines.
We do not have to implement them as methods in the name of OOP.
These can be functions still.

Piotras
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev
- Reply
Henri Bergius

Re: [midgard-dev] How about project Ragnaland?
Thu December 04 2008 19:41:29 UTC
Hi,

On Thu, Dec 4, 2008 at 9:33 PM, Piotr Pokora <piotrek.pokora@gmail.com> wrote:
> The purpose of account is to separate user's login and password from
> person's data.

Agreed. Once the midgard_user docs for this are up-to-date we can
switch Ragnaroek to that API.

Here are the places where I found password being modified:

./fi.hut.loginbroker/callbacks/createperson.php:
$person->password = "**{$this->data['password']}";
./fi.hut.loginbroker/callbacks/createperson.php:
$person->password = "**{$this->data['password']}";
./fi.hut.loginbroker/callbacks/createperson.php:
$person->password = '';
./fi.hut.loginbroker/callbacks/resetpasswd.php:
$person->password = "**{$this->data['password']}";
./fi.hut.loginbroker/callbacks/resetpasswd.php:
$person->password = $this->_local_data['pre_update_password_encoded'];
./fi.hut.loginbroker/tokenlogin.php: $person->password =
"**{$password}";
./midcom.admin.user/handler/list.php:
$person->password = '';
./midcom.admin.user/handler/user/edit.php:
$person->password = "**{$password}";
./midcom.core/midcom/core/user.php: $person->password = $password;
./midcom.core/midcom/services/auth/sessionmgr.php:
$session->password = $this->_obfuscate_password($password);
./midcom.core/midcom/services/auth/sessionmgr.php:
$session->password = $this->_obfuscate_password($new);
./net.nehmer.account/handler/register.php:
$this->_person->password =
$this->_person->get_parameter('net.nehmer.account', 'password');
./net.nemein.openid/consumer.php: $person->password = '**' .
$this->generate_password();
./net.nemein.personnel/handler/account.php:
$this->_person->password = "**{$_POST['f_password'][0]}";
./org.openpsa.contacts/person.php: $this->password = $password;
./org.openpsa.contacts/person.php: $this->password = '';

> $sg = new midgard_sitegroup($name);
> Now I realized that id to name translation is needed for higher level.
> It exists in core, should be easy to add to bindings.

Yes, we need that.

>> Does the modern API support quota in any way?
> Sure. We have size computed in metadata.
> And quota is managed by midgard_quota class defined in mgdschema.
> I just forgot about this one function which computes sitegroup size.

Also, I think we need either PHP bindings or API docs for the quota
stuff, right?

>> That is one possibility. I still feel that
>> midgard_object_class::is_guid() would feel more natural, as we already
>> have midgard_object_class::get_object_by_guid()
>
> midgard_object_class is sort of reflection class for midgard_object.
> mgd_is_guid is generic routine.

Well, I still kind of feel it would be logical to keep them together.

>> As for midgard::version(), this could simply be $_MIDGARD['version'].
>
> I think mgd_version or midgard_version function is still better than
> array's element which can be changed anywhere by anyone.
>
> In core midgard_is_guid and midgard_version are only routines.
> We do not have to implement them as methods in the name of OOP.
> These can be functions still.

True.

> Piotras

/Bergie

--
Henri Bergius
Motorcycle Adventures and Free Software
http://bergie.iki.fi/

Skype: henribergius
Jabber: henri.bergius@gmail.com
Jaiku: http://bergie.jaiku.com/
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev
- Reply
Piotr Pokora

Re: [midgard-dev] How about project Ragnaland?
Fri December 05 2008 11:26:30 UTC
Henri Bergius writes:
> Hi,

Hi!

>>> Does the modern API support quota in any way?
>> Sure. We have size computed in metadata.
>> And quota is managed by midgard_quota class defined in mgdschema.
>> I just forgot about this one function which computes sitegroup size.
>
> Also, I think we need either PHP bindings or API docs for the quota
> stuff, right?

Quota support has been written for 1.7 when only MgdSchema was the only
way to easily manage db content.
That's why there's no special API for this, and quota limits are managed
by midgard_quota table records.
Now when core is able to generate database classes I think API will be
good for easy and clear way to manage
quota limits. I will create vinland task and later port it to .4.

>>> That is one possibility. I still feel that
>>> midgard_object_class::is_guid() would feel more natural, as we already
>>> have midgard_object_class::get_object_by_guid()
>> midgard_object_class is sort of reflection class for midgard_object.
>> mgd_is_guid is generic routine.
>
> Well, I still kind of feel it would be logical to keep them together.

The more I think about this the more I am sure we need sort of module class.
Similiar to python's midgard.version() usage for example.
For such class we can add later new methods like new_guid or set_connection.

Piotras
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev
- Reply

1 2 next