Norman Maurer wrote:
> Stefano Bagnara:
> > Noel J. Bergman wrote:
> > > Also, to speak directly to your concern, please consider that we
already
> > > have JDBC and XML based VUT implementations. Doesn't it seem
reasonable to
> > > unify the mapping code by writing a VUT that is populated from user
> > > repositories? For one thing, as I noted, the account-based
alias/forwarding
> > > code happens only during local delivery, whereas virtual user table
behavior
> > > can happen anywhere in the pipeline, from in-protocol to delivery.
> > I already splitted LocalDelivery into UsersRepositoryAliasingForwarding
> > and ToMultiRepository. The first one is the one that is needed to
> > support the aliasing/forwarding. We may remove LocalDelivery from our
> > config.xml and insert the 2 mailets as separate instances so that it
> > will be much more clear what happens and when.
> +1
> Im not sure if we should do this in 2.3 or in later versions. IF we want
> todo it not now we should mark LocalDelivery as @deprecated before
> release 2.3 final.
It isn't so bad as that. :-) But it should be for later. :-)
> > This may mean that also UsersRepositoryAliasingForwarding is movable
> > around like the VUTs and that we could write a fastfail for it like for
> > VUTs.
> I don't understand this. Can you explain ?
See below.
> > I always thought that all of this stuff should be accessed via a common
> > interface so we may create services and have generic
> > mailets/matchers/fastfailfilters to access them.
> IF we could manage this this whould be great.
We already have a common interface. The UsersRepositoryAliasingForwarding
code should be rewritten as a virtual user table, following the existing
interfaces.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
