Hi John, I've been working under the assumption that VIVO would become an integral part of a deployment and would handle all related profile storage and that there would be an option to have 'simple' profiles. If we are going down that route I don't think that the existing profile service will cover all use cases. But I wanted to check on-list to make sure.
I know that some work has been done by writing Freemarker templates in VIVO which return JSON, but I haven't been able to track this work down? Simon On 7 Aug 2012, at 07:40, John Norman <[email protected]> wrote: > There is an important architectural principle that needs to be established. > Will Sakai run without Vivo? IIRC the profile design work previously assumed > that the answer to this must be 'Yes' and Vivo would just be an optional data > source. For me the interesting model would be to invert the logic and make > the answer 'No'. There might be a minimal profile service bundle that could > come with Sakai code, but full functionality would depend on a Vivo > installation. We would need to anticipate that institutional deployments of > Vivo might pre-exist Sakai and have been customised in our architectural > model. I think this is how identity management is handled in some Kuali apps > - Kuali Identity Management as a very basic module for testing, but an > assumption of integration with a full identity management system for real > installations. > > I believe there is work on permissions within the Vivo community, but I have > discussed it recently. > > Did you find Yushan's work on a profile widget pulling information out of > Vivo? > > HTH > John > > On 6 Aug 2012, at 22:24, Simon Gaeremynck <[email protected]> wrote: > >> Hi, >> >> I'm working on trying to use VIVO [1] as a possible repo to host all our >> profile information on. I've been going trough confluence and the >> user/profile bundles to determine how it might tie into Sakai and I'm >> slightly questioning if the existing codebase would be sufficient to cover >> what we need. >> >> Afaict, the (current) way to go is by using KERN-739 [2] which was created >> to handle this kind of thing. You can express external data-feeds by setting >> the 'sakai:source' property on the authprofile node (or any child thereof) >> to external. When you do a request to >> ~/simong/public/authprofile.profile.json, it will then trigger your >> ProfileProvider implementation which can deal with getting the data from the >> external source. This would also require a LiteAuthorizablePostProcessor who >> creates that property upon user creation. >> >> I've tried this approach and it does work (ie: I'm able to grab external >> data out of VIVO and bring it into sakai) but I'm wondering if this would be >> the way to go forward. It doesn't look like it was ever meant to handle full >> profiles but rather parts of a profile. ex: only publications are external. >> I've talked to Ray who has written the persondirectory contrib bundle which >> does a similar thing and he seems to be hesitant to use this kind of logic >> as it has never been really used (as far as we can tell). >> >> Some factors that might play a role into all of this are: >> - The ability to ACL certain profile data, this is something that VIVO >> doesn't provide (again: afaict) and certainly isn't trivial. >> - The ability to update profile information from within sakai. This might >> need a custom ProfileService impl ? >> >> Has anyone ever done anything like this or has some advice/ideas on what the >> best approach would be? >> >> I'll be tracking my work against KERN-3081 [3] if anyone is interested. >> >> Thanks, >> >> Simon >> >> >> >> [1] http://vivoweb.org >> [2] >> https://confluence.sakaiproject.org/display/KERNDOC/KERN-739+Dynamic+user+profiles >> [3] https://jira.sakaiproject.org/browse/KERN-3081 >> _______________________________________________ >> oae-dev mailing list >> [email protected] >> http://collab.sakaiproject.org/mailman/listinfo/oae-dev > > John Norman > Director - CARET > University of Cambridge > [email protected] > +44-1223-765367 > _______________________________________________ oae-dev mailing list [email protected] http://collab.sakaiproject.org/mailman/listinfo/oae-dev
