Danny Angus wrote:
Hi,
I've started refactoring in server/sandbox/mailet-refactorings
Initial comits moved user and mail repositories into the API.
I remember that in past there was no mail repositories in the APIs. Then
for a lot of months I saw the repositories added to the APIs, and later
they have been removed again.
I was not following so much the list to remember why this happened: can
you tell us what was the historical cause of this?
This is because it is virtually impossible to do anything with the API
without those entities.
User repo depends upon User, so I moved that too.
I think that moving only Mail and UsersRepository does not fix any
mailet: maybe we have at least to move the cornerstone.Store (previously
we were using james.services.MailStore) and UsersStore.
But I'm not sure this is the right way to go unless we want to move
almost *everything* we have in "services" to the mailet apis.
While I was at it I refactored JamesUser. JamesUser is badly named
because it has two responsibilities, forwarding and aliasing, so I
split ForwardingUser and AliasedUser out of it and, on the basis that
they are reasonably sensible email concepts, moved them into the API
as well.
d.
In the past weeks we talked about JamesUsers and the way we was
currently supporting Aliasing and Forwarding and we agreed that it was a
bit weird (you have to create a new "virtual" user to enable aliasing
for another user).
Few months ago I isolated the aliasing/forwarding code in James.java and
UsersRepositoryAliasingForwarding mailet. Few weeks ago, introducing the
VirtualUserTable service we decided that its behaviour was really
similar to what we did in UsersRepositoryAliasingForwarding so we
started a refactoring that brought us to isolate the use of
aliasing/forwarding INSIDE the specific implementation of
UsersRepository: the implementation also provide a VirtualUserTable
implementation that give you access to the alias/forward informations.
Alias and Forward have been unified to a single concept: when the
resulting address is local it is considered an alias, if the resulting
address is remote it is considered a forward.
I have not analyzed again this thing now, but I think we now don't need
the "JamesUser" or the Alias/Forward thing in the APIs as all of this is
hidden behind the UsersRepository and VirtualUserTable services.
Stefano
