rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carlucci, Tony" <acarlu...@mitre.org>
Subject RE: [DISCUSS] Proposal for Person Profile Direction in Rave
Date Tue, 07 Feb 2012 18:10:45 GMT
>-----Original Message-----
>From: Martin Steinmann [mailto:martin@ezuce.com]
>Sent: Tuesday, February 07, 2012 11:09 AM
>To: rave-dev@incubator.apache.org
>Subject: RE: [DISCUSS] Proposal for Person Profile Direction in Rave
>
>This is very much in line with our thinking as well and adding such a
>Personal Profile is an important feature for Rave, especially if Rave is to
>be seen in the context of social networking inside an enterprise.  The
>problem we see with this is that every application strives for the same goal
>and adds more and more person data, so that you end up with an IT
>infrastructure that consists of islands.  This is not very useful for most
>users as you have to create and maintain such a profile in every application
>you use, which means that these profiles are never consistent.

+1

>Once we agree on the necessity for single sign-on, you could argue that the
>authoritative source for persona data is the directory server.  Except in
>the vast majority of IT environments the LDAP / AD directory server is read
>only and therefore not suited for person profile data that the users would
>like to update without the help of an admin.

This is the same exact situation we have - we will be obtaining our person data 
from an LDAP source, and need to combine the Rave User and our MITRE Person
into one usable object that is used for authentication, database persistence,
and viewing as the source of the Person Profile.

>
>
>
>This calls for two things:  a) a standard format to store such person data,
>like vCard (RFC 6350) and xCard (RFC 6351), and b) a flexible way to store
>person data in a database.   The second point is important because instead
>of using complicated sync algorithms to keep person data synchronized
>between different applications where each application maintains its own
>database, it should be possible to use a distributed data base, such as
>MongoDB, to store person data for all applications to access.  The DB layer
>then replicates this data and makes sure that it remains consistent for all
>applications, allowing users to use any application to update their profile.

And this is the problem to solve, how do we make it flexible enough to 
support the N number of different "Person" permutations out there? 
 
Thanks for your input Martin!

>
>
>
>--martin
>
>
>
>
>
>From: Carlucci, Tony [mailto:acarlucci@mitre.org]
>Sent: Tuesday, February 07, 2012 10:07 AM
>To: rave-dev@incubator.apache.org
>Subject: [DISCUSS] Proposal for Person Profile Direction in Rave
>
>
>
>Hello Rave Community,
>
>We have internal requirements at MITRE to build out some extensive Person
>Profile functionality in Rave.   We've developed a proposal of the direction
>we'd like to take the Person Profile in Rave, since we think a lot of the
>features would be appropriate to put into the core Rave code as opposed to
>our custom extension.    Before we started creating Jira tickets, we'd like
>the community to comment on it to make sure it fits into the community's
>vision of Person Profiles.  The features below represent what MITRE needs,
>and would definitely not represent the whole feature set of Person Profiles
>in Rave.  The first 3 items are the requirements for our initial version of
>the Person Profile and what we would focus on first (essentially the "view"
>work).  The last three would be future enhancements.
>
>Thanks in advance for your time...
>
>Tony
>
>
>(1)    A Person Profile page can be viewable by any user, not just the owner
>
>a.       proposed URI mappings: /portal/app/profile/{username or entityId}
>
>b.      We would add a new field to the Page model object: boolean
>isProfilePage
>
>                                                               i.      This
>will be an indicator to the rest of the application that it is not a
>"Traditional" page object, but a "Profile" page
>
>                                                             ii.      This
>will also allow the security layer on the services  to use this field to
>allow Profile Page objects to be viewed by people other than the owner
>
>                                                            iii.
>Perhaps a more sustainable long-term solution would be to create a pageClass
>column instead of the specific Boolean, that could be "regular,
>personProfile, future-alternate-page-class", etc?
>
>
>
>(2)    The Person Profile page can contain multiple sub-pages (tabs from a
>UI perspective), each containing multiple regions and widgets
>
>a.       Create a new ProfilePage model object
>
>                                                               i.      There
>will be a one-to-many relationship between Page<->ProfilePage (one Page
>has
>many ProfilePages)
>
>                                                             ii.      Fields
>in ProfilePage
>
>1.       Long entityId
>
>2.       Page page
>
>3.       String title
>
>4.       PageLayout pageLayout
>
>5.       List<Region> regions   ***this may need to be thought out more
>since a Region object currently has a Page object attribute ***
>
>(3)    Some widgets are fixed and some have no "chrome" (border, menus,
>etc)
>
>a.       Ability to render "fixed" widgets and widgets that don't have
>"chrome" on the Person Profile page
>
>b.      The solution should be generic enough so that this also available
>for traditional pages as well
>
>
>
>(4)    The owner of the profile can edit information about themselves that
>the Rave Administrator deems editable
>
>a.       We can build on the existing edit person profile context code in
>Rave
>
>b.      Develop a mechanism that controls what person profile fields can be
>editable by a user
>
>                                                               i.      For
>example: out-of-the box we might let users update their email address, but
>for an internal corporate implementation of Rave we wouldn't want
>employees
>to be able to change that particular field
>
>                                                             ii.
>Perhaps an Admin screen that displays all person profile attributes and
>allows the admin to turn them on/off for editing?
>
>
>(5)    The composition and layout of the Profile Page can be easily editable
>
>a.       Ability to follow a similar model of customization (Drag and Drop,
>add/remove widget, etc) of a traditional Page
>
>b.      Ability to create two types of Profile Page customizations
>
>                                                               i.      Owner
>Defined Customization: I want EVERYBODY to see these customizations to MY
>profile page
>
>                                                             ii.      Viewer
>Defined Customization: I want to see this common set of customizations
>when
>viewing ANYONE's Profile Page
>
>
>
>(6)    A user can create a connection between the individual they are
>looking at and themselves from the Profile Page
>
>a.       Create a UserConnection model that connects one Rave User with
>another
>
>b.      Full API stack for managing user connections (add, remove, view,
>etc)
>
>
>
>---
>Anthony Carlucci | SW App Dev Eng, Sr. | R501 / KW App Development &
>Maint
>e: acarlucci@mitre.org<mailto:acarlucci@mitre.org> | v:
><file:///C:\Program%20Files%20(x86)\eZuce\openUC%20Outlook%20Add-
>in\StatusIm
>ages\phone.png> 781.271.2432 | f:
><file:///C:\Program%20Files%20(x86)\eZuce\openUC%20Outlook%20Add-
>in\StatusIm
>ages\phone.png> 781.271.3299
>The MITRE Corporation | 202 Burlington Rd | Bedford, MA
><file:///C:\Program%20Files%20(x86)\eZuce\openUC%20Outlook%20Add-
>in\StatusIm
>ages\phone.png> 01730-1420
>
>


Mime
View raw message