On 10/28/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
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.
Noel wanted to use JNDI for looking up services, so we abandoned the
changes which had been made to the trunk but not released.
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.
It doesn't completely fix them because we need to provide a lookup for
the services.
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.
My proposal is that we do indeed move a whole lot of our service interfaces.
But... (read this first before replying...)
We need to have an extensible mechanism which allows 3rd parties to
add services, which means that we're really talking about using JNDI
However the entities, the "things" which are handled by the services,
need to be in the API so that people can make services which work with
each other. So User and Mail go in.
Because User and Mail persistance need to be available to almost every
conievable application it makes sense to add a standard service
interface for them, otherwise you wouldnlt know how to get and put
them in your mailet.
How James chooses to implement them is not the concern of the API, and
moving the James interfaces is only a first step. They can be changed
to be more focused on the basic get and put responsibility, and less
influenced by James internals.
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).
<snip> I get it.
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.
Ok, in which case this could go out again as long as it doesn't
prevent *other* mailet containers which ight be written from providing
the same functions without mailets having to access any server
internals.
d.
