You guys have to decide what you want and build a consensus around
that. My group
intends to continue developing our mail server (although I've since
left JBoss/RedHat).
Initially we hoped to support the mailet API but there seems to be a
group who wants to
create an abstract cross-mailserver API and another group who sees it as
just an API for
JAMES. Prior to these concrete discussions you guys need to have it out
over this intent,
get the little fight over and move forward.
Following that little bit there is a question of "how far do we go?"
And that comes down to
adoption. Unless the direction is basically to where someone can go to
MailetSwap (similar to
portletswap.com/ see:
http://jboss.org/jbossBlog/blog/rrusso/2006/10/12/The_Portlet_Repository_Protocol.txt
for some idea) and get mailets that work in any mailserver then there is
next to no chance that anyone
other than JAMES will bother supporting it (obviously, why should we?).
With the
collaboration/groupware industry heating up and new players on the
scene this is the time to move...if the
will is there. Anyhow, have the REAL discussion before moving on to the
details....get the crying and hugging
it out overwith and move forward.
Just a suggestion.
-Andy
Danny Angus wrote:
On 10/28/06, Norman Maurer <[EMAIL PROTECTED]> wrote:
I don't like your changes to much. I think it make no sense to move the
Interfaces... I think we allready talked about that the MailRepository
will probaly replaced by a MessageRepository. The UserRepository
features will also replaced by the VUT Service . So why we should
move it ?
Because the API is not complete without it, the mailets have to use
James interfaces at the moment and that is not right.
If we change that *first* we can continue to change things afterwards,
including changing the services the API offers and the means of
acessing them.
At the moment what happens is that every new developer who starts
working with mailets does the same think, look-up James services
directly. We need to stop that, and the first thing to do is to make
it unnecessary.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
