You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Robert Burrell Donkin <ro...@gmail.com> on 2010/01/24 22:56:37 UTC
Re: Using VirtualUserTable as "full" replacement of alias /
forwarding
On Sun, Jan 24, 2010 at 3:15 PM, Norman Maurer <no...@apache.org> wrote:
> Hi all,
>
> here comes something which I'm thinkin of since a long time. I think
> we are now in "revolution" phase so I think this would be the right
> time to tackle this.
>
> IMHO the whole forwarding and aliasing stuff in james ( using the
> JamesUser classes) is really suboptimal. Creating a user with password
> to just use it as alias doesn't make any sense for me. So I would like
> to remove the setForwarding, setAlias methods ( at least in
> RemoteManager ) and mark the ones in JamesUser as @deprecated ( or
> just remove them ).
> The the whole forwarding and alias stuff would just get handled by the
> virtualusertable. The old aliases and forwards will still work..
IMHO the whole user API is massively overengineered. i haven't looked
into this in detail but it sounds like heading in the right direction
to me.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Using VirtualUserTable as "full" replacement of alias /
forwarding
Posted by Norman Maurer <no...@googlemail.com>.
done..
See https://issues.apache.org/jira/browse/JAMES-962
Bye,
Norman
2010/1/25 Norman Maurer <no...@googlemail.com>:
> Ok I will go ahead and just do it..
>
> Bye,
> Norman
>
>
> 2010/1/24 Robert Burrell Donkin <ro...@gmail.com>:
>> On Sun, Jan 24, 2010 at 3:15 PM, Norman Maurer <no...@apache.org> wrote:
>>> Hi all,
>>>
>>> here comes something which I'm thinkin of since a long time. I think
>>> we are now in "revolution" phase so I think this would be the right
>>> time to tackle this.
>>>
>>> IMHO the whole forwarding and aliasing stuff in james ( using the
>>> JamesUser classes) is really suboptimal. Creating a user with password
>>> to just use it as alias doesn't make any sense for me. So I would like
>>> to remove the setForwarding, setAlias methods ( at least in
>>> RemoteManager ) and mark the ones in JamesUser as @deprecated ( or
>>> just remove them ).
>>> The the whole forwarding and alias stuff would just get handled by the
>>> virtualusertable. The old aliases and forwards will still work..
>>
>> IMHO the whole user API is massively overengineered. i haven't looked
>> into this in detail but it sounds like heading in the right direction
>> to me.
>>
>> - robert
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Using VirtualUserTable as "full" replacement of alias /
forwarding
Posted by Norman Maurer <no...@googlemail.com>.
Ok I will go ahead and just do it..
Bye,
Norman
2010/1/24 Robert Burrell Donkin <ro...@gmail.com>:
> On Sun, Jan 24, 2010 at 3:15 PM, Norman Maurer <no...@apache.org> wrote:
>> Hi all,
>>
>> here comes something which I'm thinkin of since a long time. I think
>> we are now in "revolution" phase so I think this would be the right
>> time to tackle this.
>>
>> IMHO the whole forwarding and aliasing stuff in james ( using the
>> JamesUser classes) is really suboptimal. Creating a user with password
>> to just use it as alias doesn't make any sense for me. So I would like
>> to remove the setForwarding, setAlias methods ( at least in
>> RemoteManager ) and mark the ones in JamesUser as @deprecated ( or
>> just remove them ).
>> The the whole forwarding and alias stuff would just get handled by the
>> virtualusertable. The old aliases and forwards will still work..
>
> IMHO the whole user API is massively overengineered. i haven't looked
> into this in detail but it sounds like heading in the right direction
> to me.
>
> - robert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org