rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Steinmann" <mar...@ezuce.com>
Subject RE: [DISCUSS] Proposal for Person Profile Direction in Rave
Date Tue, 07 Feb 2012 16:09:08 GMT
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.


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 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.





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...


(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

                                                               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

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

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

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

b.      Full API stack for managing user connections (add, remove, view,

Anthony Carlucci | SW App Dev Eng, Sr. | R501 / KW App Development & Maint
e: acarlucci@mitre.org<mailto:acarlucci@mitre.org> | v:
ages\phone.png> 781.271.2432 | f:
ages\phone.png> 781.271.3299
The MITRE Corporation | 202 Burlington Rd | Bedford, MA
ages\phone.png> 01730-1420

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message