I'm implementing the last things for full OpenID/i-names support right now, but I have a few questions that I wanted to clarify with you first:

-- Registration --
How should a member registrate his OpenID URL/i-name? Simple use the email field and leave the password blank?

My idea is to create a OpenIDMember class (extends Member) that stores all the OpenID URL in a new table. But the problem then is how should such a member be created from the backend? Create a new button "Add OpenID member"?

What when I edit such a member? How can I modify the displayed form? It seems that the "getCMSFields()" won't be used at all!?

-- Database Integration --
To prevent attacks (namely replay attacks) I need to store some information somewhere. It would be simple if I can just use SQL statements for that without using the DataObject stuff, but I'm not sure if that's a good idea? What about database abstraction? I can post the code here or somewhere if you want.. Postgre, MySQL, SQLite are supported as well as file based storage..

Thanks,
Markus

Personal opinion (hopefully generally true) on the database issue:

Using DataObject should be the preferred method to communicate with the database (and it will make my part easier ;) ).
However if that is not possible, DB::query will always be available (as a back-up solution if something is not feasible otherwise), but as it works with raw SQL it makes portability to different databases harder.

Markus - we're currently developing some code that can be used to add "extension plug-ins" to the member table, which will let you add columsn to it if you have the openid module included.

It will need to be merged over to the gsoc branhc. I'll post more details ASAP.

Something like a decorator? That would be nice because otherwise we probably get problems since PHP supports only single inheritance and so the combination of different member types and authentication methods will get tricky.

I hope there is a way to override also the edit form. At the moment I created a new class OpenIDMember extends Member with a method getCMSFields(), but the backend still displays the same form for all type of members (also for members created with the forum module).

What do you think about using the email column only for email addresses (valid ones) and adding another column “username” which is then used for the “normal” members as username? Or – my favorite option – leave everything as it is, but require a valid email address as username?

Along with the additions Sam mentioned, there is now support in the member section of the CMS for the custom CMS fields.

Really? Where? At least in the GSoC branch it's still not supported.

As Hayden wrote me the ForumRole class should be ready, but I can't find it in the daily builds and unfortunately I have not enough rights to access the forum repository (svn://svn.silverstripe.com/silverstripe/modules/forum/trunk) even if I should (http://doc.silverstripe.com/doku.php?id=forum-installation)!?