Re: [reSIProcate] UserProfile Handling

["Scott Godin" <slgodin@xxxxxxxxxxxx>]

It is questionable as to what a "real duplicate" should contain.  The UserProfile/Profile class relationships can get quite complicated, since any profile can be created with another profile as it's base (same for UserProfiles).  For example:  Should a duplicate also copy/duplicate all base profiles (recursively)?

 

I'm not sure I understand why you need to create a "real duplicate".  To create multiple user profiles that share the same Profile settings - you can just pass the same base Profile object to both UserProfile constructors.  Pretty much all of the UserProfile settings are very specific to a particular user/identity and would need to be set differently for each user profile created.

 

Scott

---

From: Matthias Moetje [mailto:moetje@xxxxxxxxxxxx]
Sent: Thu 2/15/2007 12:15 PM
To: Scott Godin; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [reSIProcate] UserProfile Handling

Thanks for the quick response!

 

Wouldn’t it be useful to implement a better clone functionallity, then, in order to be able to create a real duplicate? If I would implement this, could I replace the current clone method (in addition to add a new constructor which takes a UserProfile as argument)?

 

Matthias

 

 

From: Scott Godin [mailto:slgodin@xxxxxxxxxxxx]
Sent: Donnerstag, 15. Februar 2007 17:38
To: Matthias Moetje; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [reSIProcate] UserProfile Handling

 

You should create one user profile for each identity (from header) that you have.  The same userprofile can be re-used for multiple simulatenous calls.  It is not really safe to be changing the default from in a user profile while it is in use.

 

Scott

 

---

From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx on behalf of Matthias Moetje
Sent: Thu 2/15/2007 11:16 AM
To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: [reSIProcate] UserProfile Handling

Hi,

 

I am just thinking about best practices for dealing with UserProfiles. My applications must make calls with different values in the FROM header through makeInviteSession. I specify the FROM through the UserProfile’s setDefaultFrom method.

 

Can I reuse the same UserProfile object without problems for calls with different FROM header? Is it OK just to setDefaultFrom before calling makeInviteSession or does dum use settings from the UserProfile at a later time so that I need to create different UserProfile objects for each makeInviteSession?

 

The problem with the latter procedure is that the UserProfile::clone method (or the constructor with the baseProfile parameter) does not really clone the UserProfile (but just the settings from the Profile class), so that the DigestCredentials collection and other properties get lost when cloning.

 

Thanks for any hints!

 

 

Best regards,

 

Matthias Moetje

TERASENS GmbH
Augustenstraße 24
80333 Munich
GERMANY

 

Phone: Fax: e-mail: Web:

+49.89.143370-0 +49.89.143370-22 info@xxxxxxxxxxxx www.terasens.com