What about this kind of an approach...
Create a UserRepository interface that does basic User stuff, then create
UserMailboxRepository (JamesUser?) interface, and UserListservRepository.
Then you could have the file implementation handle all of these by just
declaring that it implements each, and for the database you could create
separate implementations.
Anyway, I think it might be too aggressive to do more than just the mailbox
configuration now that I think about it. The mailing lists could rely on
other approaches to managing a list of accounts. (saying this because each
listserv implementation might want different flags, so the 'user repository'
is really app/mailet specific.)
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
----- Original Message -----
From: "Darrell DeBoer" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, August 12, 2001 6:51 AM
Subject: Re: Next release?
> On Sun, 12 Aug 2001 19:55, Charles Benett wrote:
> > Serge Knystautas wrote:
> > > ----- Original Message -----
> > > From: "Charles Benett" <[EMAIL PROTECTED]>
> > >
> > > > 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: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
