james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Charles Benett <char...@benett1.demon.co.uk>
Subject Re: Next release?
Date Sun, 12 Aug 2001 09:55:14 GMT
Serge Knystautas wrote:
> 
> ----- Original Message -----
> From: "Charles Benett" <charles@benett1.demon.co.uk>
> 
> > The User repository stuff isn't. It should be possible to write a tool
> > to upgrade from 1.2.1 to 1.3/ 2.0.
> 
> Good point.  Didn't realize this had changed that much.
> 
> I don't know what the long term plans are, but I was wondering what the long
> term plans for the user repository was... originally a user repository was
> just a list of usernames, and then you had an extensible name/value
> attributes per username so you could store passwords or whatever you needed.
> 
> This allowed us to have user repositories act both for local accounts, and
> for mailing lists.   The implementations didn't really support this,
> especially the Town one, but that was the design goal I believe.
> 
> The current user repository is no longer geared towards mailing lists, which
> would have different property needs (like a receive-digest flag, a moderator
> flag, etc... instead of password, alias, forward, etc...).  I can also think
> of additional attributes you may want on a mail user account such as quota
> limit, vacation message, and others.

At some stage, I'd like to migrate interfaces User and UserRepository
down to Phoenix/ Cornerstone. I think that would allow us to have better
control over the server, in terms of starting/ stopping/ reconfiguring.
This would replace setting the root password in the config.xml file
Remote Manager block. So, I tried to keep the User interface as simple
as possible - so it could be used in any server application running on
Phoenix. (It might need a group or role attribute). Also, the interface
does not have a getPassword method and the DefaultUser implementation
hashes the passwords.

JamesUser extends User and is meant to hold all the per-user local-user
data, so that's the place to add quota limits, vacation messages etc.

I think the list stuff works as it is - the list mailets in cvs don't
use the extra attributes you mention. But we could easily have
ListMember extends User or extends JamesUser as appropriate, with those
attributes.

At the moment, UsersFileRepository handles User and any subtype (eg
JamesUSer, but UsersJDBCRepository doesn't.
Darrell - can you rework UsersJDBCRepository so that it can handle any
arbitrary subtype of User? That would be v cool.

We could then move the UserStore block to avalon (where I think it
belongs), leaving just the application specific interfaces: JamesUser,
ListMember and their implementations in James.



> 
> > The architecture has changed quite a bit. 1.2.1 was - as I recall - a
> > monolithic block whereas current code is a server application with
> > multiple blocks.
> >
> > We have an additional, full functional server - NNTP.
> >
> > As a side line, the current default is for SMTP, POP3, NNTP and IMAP
> > servers to start. Do people think this makes sense or would it be better
> > to turn off NNTP and IMAP in default settings? (This should be doable by
> > editing conf files)
> 
> +! to turning off NNTP and IMAP in the default settings.

I'll try to look at it this week.

Charles

---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org


Mime
View raw message