You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@rave.apache.org by "Franklin, Matthew B." <mf...@mitre.org> on 2012/08/28 23:23:03 UTC

Separation of Person & User

We have discussed separation of User & Person in the past [1]; but, have yet to take action to modify the current inheritance model.  I have been working on separating out direct references to people in the model split branch and have gotten to the point where I am ready to take on this User/Person split.  

I plan on just splitting the interfaces and noting that there is a logical constraint that Id & Username (both properties of Person & User) MUST be the same between the two objects.  I also plan to remove any profile or "person" information from the User interface and ensure that it is part of Person and moving any operations that are related to people (friends, etc) into the person service.  

Thoughts?

[1] http://s.apache.org/l1C

RE: Separation of Person & User

Posted by "Carlucci, Tony" <ac...@mitre.org>.
>-----Original Message-----
>From: Franklin, Matthew B. [mailto:mfranklin@mitre.org]
>Sent: Tuesday, August 28, 2012 5:23 PM
>To: dev@rave.apache.org
>Subject: Separation of Person & User
>
>We have discussed separation of User & Person in the past [1]; but, have yet to
>take action to modify the current inheritance model.  I have been working on
>separating out direct references to people in the model split branch and have
>gotten to the point where I am ready to take on this User/Person split.
>
>I plan on just splitting the interfaces and noting that there is a logical constraint
>that Id & Username (both properties of Person & User) MUST be the same
>between the two objects.  I also plan to remove any profile or "person"
>information from the User interface and ensure that it is part of Person and
>moving any operations that are related to people (friends, etc) into the person
>service.
>
>Thoughts?
>
>[1] http://s.apache.org/l1C

+1

Tony

RE: Separation of Person & User

Posted by "Franklin, Matthew B." <mf...@mitre.org>.
>-----Original Message-----
>From: Viknes B [mailto:viknesb@msn.com]
>Sent: Wednesday, August 29, 2012 1:33 AM
>To: dev@rave.apache.org
>Subject: Re: Separation of Person & User
>
>
>
>-----Original Message-----
>From: Chris Geer
>Sent: Tuesday, August 28, 2012 5:46 PM
>To: dev@rave.apache.org
>Subject: Re: Separation of Person & User
>
>On Tue, Aug 28, 2012 at 2:23 PM, Franklin, Matthew B.
><mf...@mitre.org>wrote:
>
>> We have discussed separation of User & Person in the past [1]; but, have
>> yet to take action to modify the current inheritance model.  I have been
>> working on separating out direct references to people in the model split
>> branch and have gotten to the point where I am ready to take on this
>> User/Person split.
>>
>> I plan on just splitting the interfaces and noting that there is a logical
>> constraint that Id & Username (both properties of Person & User) MUST be
>> the same between the two objects.  I also plan to remove any profile or
>> "person" information from the User interface and ensure that it is part of
>> Person and moving any operations that are related to people (friends, etc)
>> into the person service.
>>
>
>+1
>+1 for Splitting User & Person.
>
>>
>> Thoughts?
>>
>
>The only question I have is about OpenID authenticated users. There has
>been some recent discussion on that and friends [1]. I'm assuming when you
>do this you will require new OpenID folks to select a local username to map
>to their accounts in Rave correct?
>
>If Person(not just JpaPerson) is going to have Id & Username, then there
>would
>not be any problem even for OpenID users as we can use Id in places where
>username(in this case URL) is not usable. If we are going to use a username
>for
>OpenID users, the idea now is to use a username internally by stripping
>the leading ‘http://’ from URL and the trailing ‘/’.
>I guess we are not allowing the user to select the username. Pls correct me if I
>am wrong.

This is a bit anecdotal, but most of the sites I have been to that use OpenID require me to still setup an account that is bound to the OpenId URL.  I was thinking that what we would do is send the user to a new user form and have them add a username but no password if they login with an openID that we do not have in the system.  

IMO, this work should be deferred until we merge back to trunk as it will require a bit of machinery and is tangential to the goal of the model split task.  For the time being, I was going to keep Raminder's strategy in place.

>
>
>[1]
>http://mail-archives.apache.org/mod_mbox/rave-
>dev/201208.mbox/%3C20120822174022.15256.35808%40reviews.apache.org%
>3E
><http://mail-archives.apache.org/mod_mbox/rave-
>dev/201208.mbox/%3C20120822174022.15256.35808%40reviews.apache.org%
>3E>
>
>>
>> [1] http://s.apache.org/l1C
>>

Re: Separation of Person & User

Posted by Viknes B <vi...@msn.com>.

-----Original Message----- 
From: Chris Geer 
Sent: Tuesday, August 28, 2012 5:46 PM 
To: dev@rave.apache.org 
Subject: Re: Separation of Person & User 

On Tue, Aug 28, 2012 at 2:23 PM, Franklin, Matthew B.
<mf...@mitre.org>wrote:

> We have discussed separation of User & Person in the past [1]; but, have
> yet to take action to modify the current inheritance model.  I have been
> working on separating out direct references to people in the model split
> branch and have gotten to the point where I am ready to take on this
> User/Person split.
>
> I plan on just splitting the interfaces and noting that there is a logical
> constraint that Id & Username (both properties of Person & User) MUST be
> the same between the two objects.  I also plan to remove any profile or
> "person" information from the User interface and ensure that it is part of
> Person and moving any operations that are related to people (friends, etc)
> into the person service.
>

+1
+1 for Splitting User & Person.

>
> Thoughts?
>

The only question I have is about OpenID authenticated users. There has
been some recent discussion on that and friends [1]. I'm assuming when you
do this you will require new OpenID folks to select a local username to map
to their accounts in Rave correct?

If Person(not just JpaPerson) is going to have Id & Username, then there would 
not be any problem even for OpenID users as we can use Id in places where 
username(in this case URL) is not usable. If we are going to use a username for 
OpenID users, the idea now is to use a username internally by stripping 
the leading ‘http://’ from URL and the trailing ‘/’. 
I guess we are not allowing the user to select the username. Pls correct me if I am wrong.


[1]
http://mail-archives.apache.org/mod_mbox/rave-dev/201208.mbox/%3C20120822174022.15256.35808%40reviews.apache.org%3E
<http://mail-archives.apache.org/mod_mbox/rave-dev/201208.mbox/%3C20120822174022.15256.35808%40reviews.apache.org%3E>

>
> [1] http://s.apache.org/l1C
>

Re: Separation of Person & User

Posted by Chris Geer <ch...@cxtsoftware.com>.
On Tue, Aug 28, 2012 at 2:23 PM, Franklin, Matthew B.
<mf...@mitre.org>wrote:

> We have discussed separation of User & Person in the past [1]; but, have
> yet to take action to modify the current inheritance model.  I have been
> working on separating out direct references to people in the model split
> branch and have gotten to the point where I am ready to take on this
> User/Person split.
>
> I plan on just splitting the interfaces and noting that there is a logical
> constraint that Id & Username (both properties of Person & User) MUST be
> the same between the two objects.  I also plan to remove any profile or
> "person" information from the User interface and ensure that it is part of
> Person and moving any operations that are related to people (friends, etc)
> into the person service.
>

+1

>
> Thoughts?
>

The only question I have is about OpenID authenticated users. There has
been some recent discussion on that and friends [1]. I'm assuming when you
do this you will require new OpenID folks to select a local username to map
to their accounts in Rave correct?

[1]
http://mail-archives.apache.org/mod_mbox/rave-dev/201208.mbox/%3C20120822174022.15256.35808%40reviews.apache.org%3E
<http://mail-archives.apache.org/mod_mbox/rave-dev/201208.mbox/%3C20120822174022.15256.35808%40reviews.apache.org%3E>

>
> [1] http://s.apache.org/l1C
>