>>>2. seperation api and impl makes james a more reusable proposition (when
>>> viewing james a compositie component)
>>You are missing the point that the API changed, and code relying upon the
>>new API would not be compatible with the older API. Like how a program
>>requiring java.nio won't work with JDK 1.3.
>Ok so if I underand correctly - 3.0a1 contains JDK 1.4 dependencies and
>that the 2.1/2.2 stuff is based on 1.3.1.
Close. It contains Mailet API dependencies. Things that were internal
became exposed, and it is unclear that we want to preserve those
experimental changes. MAIN is a development branch, not production.
> If that's correct - then in reality the 2.1/2.1 content is what I should
be
> considering as the MAIN branch.
If you mean production, then yes. The v2 branch is the stable production
branch, and MAIN was the development branch.
> However, to get this in sync. we would need to backport all of
> the Componet/Service migration stuff that was put into HEAD way
> back (which is something I'm not looking forward to).
I don't know that it can be helped, except where there the only differences
are the Avalon changes.
> And just to confirm again - the core problem is 1.4 in HEAD versue 1.3
> in MAIN ?
Again, that was an analogy. See above. Basically, the Mailet API in v2
does not expose the repositories. The one in MAIN does, and shuffled other
things around, and it is absolutely not clear that we want to expose some of
the changes that were made. I think we don't, but either way we certainly
don't want to be stuck with it, since we haven't made it as Release.
> james should move to a container neutral build which means some
> restructuring.
If someone wants to do that work, we should. For that matter, if someone
wants to fix a container so that it supports proper logging, it could become
the default container shipped with James (assuming that it passes
functional, load and performance testing).
> I still think/assert that a formal api/impl seperation would be *really*
> valuable in terms of (a) immediate reusability of james subsystems, and
> (b) future initative related to james scalability.
IMO, the published version of Mailet API in a Release is the only public
guarantee. The rest are server internals. And that flexibility is
necessary to ensure future scalability.
> Anyway - I could checkout the MAIN (2.1/2.2? branch) of james and start
> looking at things. Which is the actual CVS tag I should reference?
branch_2_1_fcs is the generic v2 branch, pre-experimental Mailet API
changes.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
