Robert Burrell Donkin wrote on 29 January 2008 21:28: > 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.
Right now the Mailet interfaces are implementation agnostic. A James specific Mailet is a contradiction as any dependency on James breaks the Mailet rules. This is good in as much as it allows James interfaces to evolve independently of the Mailet APIs. This is bad in that it limits what can be done within a Mailet in the James environment, but this is like saying that similar APIs, such as the Portlet API are bad because I know that the environment hosting my Portlet knows and can do more. Its the price paid for portability. I see this as a separate issue from publishing James specific extension points (see below). > > 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 :-) Sure, the APIs are 'public' in the sense that in Java interfaces are code 'public' and with OSS the code is itself public, so we do not have the luxury that commercial developers have to hide Java public code. This is not to say that every Java public artefact within James should be bound to follow a rigid set of rules. If it is not published as an extension point I'd say we are free to do as we wish. Some OSS projects go as far as marking even new public artefacts as deprecated, meaning that they may change or be removed in the future to make this very clear. For me, this is overkill. Extension points are simply the ones we publish in the docs. with the release. Code public should mean nothing to the wider community. To be clear, such extension points are unrelated to the Mailet API and are James specific. > we're just not doing a good job of telling independent developers > which APIs will be preserved between versions and which may change Because at this stage we don't know! As long as we are honest I don't see there is anything wrong with this. The answer will be in the roadmap. > - robert -- Steve --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
