2010/12/16 Stefano Bagnara <apa...@bago.org>: > 2010/12/16 Norman Maurer <nor...@apache.org>: >> Hi there, >> >> as we are currently doing last changes in the API before the next >> release I would like to get rid of the UsersStore interface and >> implementation. >> >> Here some background: >> >> In previous version of James Server we allowed to configure more then >> one UsersRepository and lookup each by its unique name. We forced the >> User/Dev to specify at least one UsersRepository which need to have >> the name "LocalUsers". This one was used as the "default" which were >> used to back all "local" users. Beside this you could configure a >> second one and use it in some mailets. Anyway most of our code was >> bound to use the "LocalUsers" one to check for valid user etc. So I >> don't see much value to support more the one at the same time. It just >> complicate stuff and needed some ugly hacks to get it workin all the >> way. >> >> The only "service" which make really use of the UsersStore and so more >> then one UsersRepository is the mailinglist stuff. But I think its >> just plain wrong to use it here. The maillinglist use one >> UsersRepository per mailinglist to store eachs users. Anyway using the >> UsersRepository for this is just a misusage of a component, as it was >> not really designed for that purpose. The mailinglist in fact only >> need some kind of storage which map mail-addresses to the right list. >> Nothing more. >> >> So I propose to remove UsersStore and just use one UsersRepository. >> For the mailinglist we have two options: >> >> 1) Remove the mailinglist stuff >> 2) Write some simple store for it. >> >> I think 1 would be the fastest but maybe users still like to use it. >> I'm in fact never did so I would be ok with removing it too. >> >> So what others think about it ? > > I agree with you. I never used the mailing list stuff and also can't > remember users asking questions about that. > > Maybe the best thing in order to generically support persistence for > generic mailets is to add some kind of "persistent map" in the mailet > api. This way a mailet can define "named" maps and make simple > add/remove/lookup from that maps without knowledge about the real > persistence and containers can provide files/db or any other > implementation. >
I agree with you that this would make sense. Anyway I think its hard to come-up with something generic enough to work for all cases. > This "map" stuff can also be found in other system like sendmail where > they even provide a tool to build a db from the file based maps (this > is used for the domainlist, for the aliasing, for the relay server > definitions) and maybe for more. > > If a mailet needs something more "complex" than simple maps it can > implement it's own serialization method for the value. Yeah I agree as stated aboce > > Maybe this would allow us to remove direct JDBC/Store references from > some mailet (most of the mailets that we still bundle in james instead > of mailet project). Then it could easily allow to write an > administrative interface (or JMX) to see defined map and alter their > content. > > Stefano I think for now we could just tag current trunk and remove all the mailetlist stuff. If we dedicite later we still need or want it we can merge it back. WDYT ? Bye, Norman --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
