Hello, Thanks for your comment upon proposal. I'll try to answer the questions that you've stated.
> * Adding columns to the db for "openid_*" seems a little hokey to me. > Is it not better to find a generic (meaning non-openid specific) way of > accomplishing this? We are bound to run into a situation like this > again in the future and I don't think messing with the schema every time > is the best solution. If it is not recommended to modify database schema, then we can store that information on the xml file or any other type of file. If you can think of any other ways of accomplishing this, I'll take it into consideration. One of the issues to discuss in the proposal was the question whether the user can have one or more openid_urls mapped to his account. In the case when user can have multiple openid_urls, it's essential to create one more database table to store userids and corresponding openid_urls. If the user can have only one openid_url, it would be possible not to create one more table, just add column to the rolleruser table, or reuse any of the existing columns > * Is it expected that openid users will get a local account provisioned? > or are we planning this such that these users would be managed > externally, similar to an ldap directotry scenario? Yes, users with openid will have the same type of account as regular users. As far as existing users would have the opportunity to attach openid_url to their account. I guess, it'll increase usability, as far as compatibility and speed. > * A tricky part that will need more consideration is the comment > authentication part. In particular, Roller currently does not allow a > situation where an authentic user is not also available via lookup in > the UserManager. This will need some revising. I guess, openid authentication won't change any of the user lookup methods, so everything except the authentication process will be the same. The result of the authentication will be the User class instance, and all other methods will use its id, name, etc. the same way. Tatyana
