-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 But these are all good points, Ioan. The initial user population process (for accounts canonical, john.doe, etc) is just for demonstration. Adding LDAP would be great. Also the NoSQL backend would be nice. I don't know how well Spring supports any of these, however.
Marlon On 10/20/11 6:08 PM, Marlon Pierce wrote: > The openID parts could use more work. For example, we don't have a way to > associate an openId with an existing account (like john.doe). > > > > Marlon > > > On 10/20/11 6:04 PM, Hadrian Zbarcea wrote: >> Done. > >> https://issues.apache.org/jira/browse/RAVE-23 > >> Hadrian > >> On 10/20/2011 02:52 PM, Ioa Kiss wrote: >>> Hi All, >>> >>> I am running some tests with Rave and I find it very interesting. >>> >>> I was wondering about how Rave handles users/account. My understanding is >>> that Rave is a standalone portal, you create an account and then login and >>> manage your widgets. Is my assumption correct? >>> >>> I would propose a use case where Rave is a portal that sits on top of >>> another application and therefore the accounts are uploaded and not created >>> by a user. Such uploading could happen in different ways. >>> >>> 1. One way would be an LDAP connector with LDAP bind authentication >>> and the ability to upload profile data from LDAP. >>> >>> 2. Another way would be openID where you authenticate against an >>> existing application that is an openID provider. You then want to build an >>> ability to add a plugin that connects into a proprietary REST API to upload >>> profile data (i.e. when a user logs in for the first time using openID, the >>> account in Rave is automatically created and the profile data uploaded). >>> Once the account exists you have to be able to sync profile changes both >>> ways. >>> >>> >>> >>> Another question is related to the database used by Rave. I noticed that >>> currently MySQL is used as database. I was wondering what do you think about >>> using a NoSQL DB with Rave? I think this would give Rave better scale and >>> the possibility for redundancy. >>> >>> >>> >>> Thanks, >>> >>> Ioan >>> >>> >>> >>> -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOoJzoAAoJEEfVXEODPFIDGWoH/32d8jJRV3/fUrRPmkveoo+U gDT00OjE/WUCwplZIwp9w/nwwR1chrXEXQn4jl8xdsWc5WUJmRJNyUmnRw5igm2k FtNL+diNz3qqhZS48JCk0kkq56M78ikKJCZZCB1geEsDhcd9F5J/R3VKpw74nI7c EdxG2fG5ytfeWKeHGjAgat6aE1uwfCeBfMLPclsSEpGQ3NMTaQ6tWIc8pkicBO18 Ofwtr3mERfojIDoEt3DBwH9uZ/aAuSmey+ZCYuCYG9+4tiVUjwr7GqdIIDdJJHE+ 7mzqhryOT5nuJnhMRsGLOL/7Nw6AEJCc0BPMBE5lvtOJCdWFLds1aEPiuyCKGyA= =D4Xh -----END PGP SIGNATURE-----
