Move Plos Registration database to Mulgara

Because registration/authentication was always supposed to be separate from the main application. You don't want to rely on the fact that you can share data between the two entities. While one could argue that it is an arbitrary storage mechanism, the initial intent was to have a complete separation between registration/authentication and the plosone application. If you wanted to move the database over to mulgara and create a completely separate model for it all, I guess you could do that, but it seems like that would complicate mattters. If you want to get rid of a database, you could always use the mysql database for registration. However, we originally thought you would be using postgres anyways, so it seemed liked we might as well go with postgres on our side.

Replying to stevec:

Th main reason for the re-think is for simplifying the install process rather than a need to share the data. The registration data then becomes a separate Model (or installed on a seperate Mulgara database if isolation is desired for load/security reasons). Also mysql requirement may be eliminated if the Blobs are managed via Mulgara.

A seperate issue on the same line of thought: PlosOne? WebApp? should be made CAS agnostic. This way as we prepare to release this as open source, installation would be a breeze. PlosOne? production itself would use CAS or whatever SSO options; but developers or other organizations evaluating the viability of this platform would find it easy to set it up 'out-of-the-box' without much tweaking.

Replying to pradeep:

Replying to stevec: Th main reason for the re-think is for simplifying the install process rather than a need to share the data. The registration data then becomes a separate Model (or installed on a seperate Mulgara database if isolation is desired for load/security reasons). Also mysql requirement may be eliminated if the Blobs are managed via Mulgara.

Sure, if that's the direction you want to go, there is nothing preventing that from happening. The registration code will have to use the OTM annotations rather than the Hibernate annotations. Some code will have to be written for CAS as they don't come with out of the box support for mulgara.

A seperate issue on the same line of thought: PlosOne? WebApp? should be made CAS agnostic. This way as we prepare to release this as open source, installation would be a breeze. PlosOne? production itself would use CAS or whatever SSO options; but developers or other organizations evaluating the viability of this platform would find it easy to set it up 'out-of-the-box' without much tweaking.

The intent was always to make it SSO agnostic. We just never had time to abstract things. I don't entirely see how making it agnostic would make it easier to install/evaluate. you'd still have to hook it up to some sort of authentication mechanism. Some samples of how to hook it up to some sort of LDAP server may be helpful if the desire is to make things easy to evaluate.

Not feasible for the 0.8 release.

Milestone WishList? deleted

This needs to be done to get rid of dependency on Postgres. It will simplify installation and administration a little bit.

On hold until after upgrade to CAS 3.3.1