james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexis Agahi <a...@users.sf.net>
Subject Re: James & OpenIM story? (next move?)
Date Wed, 08 Oct 2003 06:51:56 GMT
On Wednesday 08 October 2003 03:57, Noel J. Bergman wrote:
> > Should we wait for Merlin 3.1 featuring JMX & extended logging?
> > (BTW I could help Steve on this task to boost the release cycle)
> Is your code unable to run with Phoenix?  As Stephen is wont to say, we
> should try to be container agnostic.

Could be run on phoenix, (as any components) but we use AMTAGS, so this would 
required a lot of work to be phoenix friendly. 
But on the other side, James can work on Merlin (Steve seems to using it 
everyday ;) )...

> > Or could we start thinking about a common user base?
> > How about something like a cornerstone user manager?
> The major problem that I have with a Cornerstone User Manager is that
> nothing in Avalon is a standard in any way.  We will not expose Avalon APIs
> via the Mailet API in James v3.  The planned direction is standards-based
> using, for example, JNDI.  Using a common standard, when it is a good one
> and matches well, offers significant benefits.  You can already see other
> Java platforms, e.g., Tomcat and BEA WebLogic converging on JNDI + JAAS as
> the standard interface.
> I have only been looking at the AAA RFCs (http://www.aaaarch.org/) for a
> few weeks, but do agree with Alex and Vincent that AAA + JNDI looks a good
> route.  Sun, as you may be aware, participated in the AAA RFCs, and I am
> curious to see what comes out of the JCP.

Will take a look asap. Give my feedback, but should'nt we establish what could 
be set in common ?

> My point being that Avalon ought to be focused on container implementation,
> and such code as is necessary to provide IoC/SoC on top of standard
> components where appropriate.  Wherever possible, standard frameworks
> should be adopted.


> It does appear that there are multiple people interested in this work, so
> that's a good thing.



To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message