On Jan 28, 2008 2:37 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > > Robert Burrell Donkin ha scritto: > > On Jan 26, 2008 4:48 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > >> Robert Burrell Donkin ha scritto: > >>> On Jan 24, 2008 10:51 AM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > >>>> That's why I think config.xml and storage compatibility should be a > >>>> greater priority compared to API stability. > >>> JAMES needs more active developers. releasing unstable APIs damages > >>> the development ecology. > >> It's clear we have different opinions on this. > >> > >> IMHO most JAMES developers are JAMES users that knows JAVA and in a > >> given point in time decide they want to start writing some Mailets, and > >> then move writing some service and then start hacking the core, and > >> become more involved in the developers community. > > > > exactly :-) > > > > mailet authors should be able to rely on a stable set of basic > > exterior service APIs. breaking into finely grained components is > > great but it creates a lot of interior interfaces to allow > > implementations to be extended. it isn't clear which APIs are intended > > for mailet and protocol developers, and which are interior APIs aimed > > at extenders of a particular backend implementation. > > > > - robert > > AFAIK only Mailet API are intended for mailet developers, now. > > And we never exposed "public" protocol APIs.
that's the point: developer wanting to independently extend JAMES are faced with moving targets and the JAMES team are faced with worries about breaking API compatibility > Only SIMPLE mailets can be written using public APIs. Everything else, > is JAMES Server core hacking (access the ServiceManager via a context > lookup and know what is declared in the assembly). > > Long before I joined this project I know that JAMES PMC evaluated the > possibility to put repositories knowledge in the mailet apis and some > more service, but I think it never landed the official code. I don't > know why. > > IMHO internal apis can be made public only when we used it for a while > and we are satisfied with them to say that we won't change them for a > while. This is not the case of current and past internal interfaces. they are already public :-) we're just not doing a good job of telling independent developers which APIs will be preserved between versions and which may change - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
