Mailing List Archive: Trac: Users

IUserInfoProvider (was: plans for component architecture)

Index | Next | Previous | View Threaded

manu.blot at gmail

Dec 4, 2005, 1:33 PM

Post #1 of 10 (1602 views)
Permalink

IUserInfoProvider (was: plans for component architecture)

Hi,

Is there any news about defining/implementing this new interface ?

class IUserProvider(Interface):

def get_known_users(attrs=('name', 'email'), limit=None):
pass

def get_user_attribute(user, attr):
pass

def get_supported_attributes():
pass

cmlenz at gmx

Dec 4, 2005, 3:49 PM

Post #2 of 10 (1598 views)
Permalink

IUserInfoProvider (was: plans for component architecture) [In reply to]

Am 04.12.2005 um 20:32 schrieb Emmanuel Blot:
> Hi,
>
> Is there any news about defining/implementing this new interface ?
>
> class IUserProvider(Interface):
>
> def get_known_users(attrs=('name', 'email'), limit=None):
> pass
>
> def get_user_attribute(user, attr):
> pass
>
> def get_supported_attributes():
> pass

Questions:

1) How about `IUserDirectory` for the name?

2) Where is this interface intended to be used? Which component
should define the corresponding extension point?

3) How is this related to the current user-settings-session-table story?

Cheers,
Chris
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/

manu.blot at gmail

Dec 4, 2005, 4:40 PM

Post #3 of 10 (1612 views)
Permalink

IUserInfoProvider (was: plans for component architecture) [In reply to]

> 1) How about `IUserDirectory` for the name?

I'd like this one, yes, good suggestion.

> 2) Where is this interface intended to be used? Which component
> should define the corresponding extension point?

I see several locations where the interface is used:

1/ In Notification subsystem: it would superseed the
"NotifyEmail.email_map", I believe
2/ In Env: it would superseed the get_known_users
3/ In SettingsModule: it would allow to store/retrieve the user name
and the email address - I guess this means that the storage (and the
retrieval) of these parameters should not always been related to the
session, or from another perspective that the session manager should
implement this new interface ?

> 3) How is this related to the current user-settings-session-table story?

I don't really know how the session stuff works.

Introducing this new interface might split the "session" table in two
new tables:
1/ Cookie - unique user identifier relation
2/ unique user identifier - user details relation
?

Cheers,
Manu

sergey at optimaltec

Dec 4, 2005, 5:32 PM

Post #4 of 10 (1598 views)
Permalink

IUserInfoProvider (was: plans for component architecture) [In reply to]

Emmanuel Blot wrote:

>>3) How is this related to the current user-settings-session-table story?
>>
>>
>
>I don't really know how the session stuff works.
>
>Introducing this new interface might split the "session" table in two
>new tables:
> 1/ Cookie - unique user identifier relation
> 2/ unique user identifier - user details relation
>?
>
>
This would be great! May I suggest that IUserDirectory is implemented by
the code in charge of item #2 above so that such code and stuff that
belong to it (UI that shows up when clicking on Settings, the table with
user details, etc.) becomes just one of possible providers for this
extension point?

Sergey.

manuzhai at gmail

Dec 5, 2005, 1:18 AM

Post #5 of 10 (1597 views)
Permalink

IUserInfoProvider (was: plans for component architecture) [In reply to]

> 2) Where is this interface intended to be used? Which component
> should define the corresponding extension point?

I think the implementation should be a new UserDirectory object that
is instantiated as an env env variable (env.users for example, or
env.udir). I seem to remember that there was a way to specify that the
interface can only be implemented by one live object, that would be
useful here.

Regards,

Manuzhai

me at brucec

Dec 5, 2005, 11:22 AM

Post #6 of 10 (1606 views)
Permalink

IUserInfoProvider (was: plans for component architecture) [In reply to]

On 12/5/05, Manuzhai <manuzhai [at] gmail> wrote:
> I think the implementation should be a new UserDirectory object that
> is instantiated as an env env variable (env.users for example, or
> env.udir). I seem to remember that there was a way to specify that the
> interface can only be implemented by one live object, that would be
> useful here.

I agree that env.users is a good place for the extension point.
However, I don't agree that there should be only one active
implementation at a time. That will be the typical configuration, but
some people may want to provide user information from multiple
sources; I see no reason to prevent that.

--Bruce

brad at dsource

Dec 5, 2005, 11:27 AM

Post #7 of 10 (1592 views)
Permalink

IUserInfoProvider (was: plans for component architecture) [In reply to]

Bruce Christensen wrote:
> On 12/5/05, Manuzhai <manuzhai [at] gmail> wrote:
>
>>I think the implementation should be a new UserDirectory object that
>>is instantiated as an env env variable (env.users for example, or
>>env.udir). I seem to remember that there was a way to specify that the
>>interface can only be implemented by one live object, that would be
>>useful here.
>
>
> I agree that env.users is a good place for the extension point.
> However, I don't agree that there should be only one active
> implementation at a time. That will be the typical configuration, but
> some people may want to provide user information from multiple
> sources; I see no reason to prevent that.
>
> --Bruce

Anybody have any code or taken a shot at this? I've been away and
haven't given it a whirl.

BA

me at brucec

Dec 5, 2005, 11:39 AM

Post #8 of 10 (1616 views)
Permalink

IUserInfoProvider (was: plans for component architecture) [In reply to]

I don't think that anyone has started on it apart from the work we did
on fleshing out the API [1] when you initiated the discussion last
month.

I'm planning to spend some time working on the gallery plugin [2] when
school gets out for break (16 December). I'd be happy to add this
refactoring to my todo list if no one else has begun by then.

--Bruce

[1] http://lists.edgewall.com/archive/trac/2005-November/005515.html
[2] http://lists.edgewall.com/archive/trac/2005-November/005526.html

On 12/5/05, Brad Anderson <brad [at] dsource> wrote:
> Anybody have any code or taken a shot at this? I've been away and
> haven't given it a whirl.

brad at dsource

Dec 9, 2005, 3:24 PM

Post #9 of 10 (1606 views)
Permalink

IUserInfoProvider (was: plans for component architecture) [In reply to]

Bruce Christensen wrote:
> I don't think that anyone has started on it apart from the work we did
> on fleshing out the API [1] when you initiated the discussion last
> month.
>
> I'm planning to spend some time working on the gallery plugin [2] when
> school gets out for break (16 December). I'd be happy to add this
> refactoring to my todo list if no one else has begun by then.
>
> --Bruce
>
> [1] http://lists.edgewall.com/archive/trac/2005-November/005515.html
> [2] http://lists.edgewall.com/archive/trac/2005-November/005526.html
>
> On 12/5/05, Brad Anderson <brad [at] dsource> wrote:
>
>>Anybody have any code or taken a shot at this? I've been away and
>>haven't given it a whirl.
>
>

I attached a patch for this functionality to bug 2456 on Edgewall's server.

http://projects.edgewall.com/trac/ticket/2456

Let me know what you think. Also, there are dev notes here:
http://trac.dsource.org/projects/test/wiki/UserDirectory

Cheers,
Brad

brad at dsource

Dec 15, 2005, 9:29 AM

Post #10 of 10 (1600 views)
Permalink

Re: IUserInfoProvider (was: plans for component architecture) [In reply to]

Brad Anderson wrote:
> I attached a patch for this functionality to bug 2456 on Edgewall's server.
>
> http://projects.edgewall.com/trac/ticket/2456
>
> Let me know what you think. Also, there are dev notes here:
> http://trac.dsource.org/projects/test/wiki/UserDirectory
>

Patch 2 is out there on bug #2456...

* get_known_user_info() returns username,name,email like legacy Trac
code is expecting (heh heh, 'legacy' Trac code)
* get_known_users() returns only username, as its name suggests
* began using the 'limit' parameter, but could use some critique of my
Python code
* still nothing with attributes

Enjoy,
Brad

_______________________________________________
Trac mailing list
Trac [at] lists
http://lists.edgewall.com/mailman/listinfo/trac

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads