2010/12/16 Norman Maurer <nor...@apache.org>: > 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 ?
+1 Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
