james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Darrell DeBoer ...@bigdaz.com>
Subject Re: Next release?
Date Sun, 12 Aug 2001 10:51:42 GMT
On Sun, 12 Aug 2001 19:55, Charles Benett wrote:
> 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.

I wasn't aware of the grand plans for the UserStore! The problem with db 
storage for "flexible" data is that it's tricky to add attributes to an 
existing installation, because the existing table needs to be modified. Sure, 
we can create migration tools to do this stuff, but it's non-trivial.

I'm not sure it will be all that practical to handle arbitrary User subtypes 
in a DB, without a big development effort. This will pretty much involve full 
OR mapping, and I'd be very reluctant to go down that path. (If only because 
that's what I do at work...) If that's what we need, then we should look at 
using an OR mapping tool (like Turbine Peers?). But I'd like to wait until 
it's necessary. 

I'd rather keep the database implementations pretty light-weight, maybe 
adding a custom mapping for a ListUser as well. It's not much work to add a 
new UserRepository implementation. One simple possibility for handling 
arbitrary user attributes is just to use a an userid-attribute-value mapping 
in a table, but there's not much point using a database for storage then, I 
suppose...

On the other hand, an XML-backed UserRepository may be more useful. It's easy 
for administrators to view, understand and modify, and easy for us to extend 
with more attributes.

Maybe the UserStore block could be responsible for working out which 
repository implementations can handle which different User subclasses, 
handing them out accordingly. I'd also like to add a "createUser()" factory 
method to UsersRepository, to be used for creating new User instances.

ciao
Daz

>
> 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

---------------------------------------------------------------------
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