On Feb 2, 2008 12:57 PM, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > i agree in principle but trunk has a lot of JAMES-specific mailets > (but i suspect that many of these could be decoupled)
Very many of them can. > > i think that it would be a good plan to pull out those mailets which > are conceptually independent into separate a subproject (standard > mailets, say) Agreed, it would be fairly easy to do. > > the problem is that many common problems solved by mailets require > access to basic services Yeah. In the sandbox i did this using JMS lookup for services, and moved several interfaces from JAMES to MAILET to de-couple. There is (was?) a lot of inconsistency around the use of Repository and Store, I favour Store as a interface to a specialised repository lookup because it can be used to provide access to "logical" repositories within a physical store. There's also some design/modelling confusion in the area of users and accounts. > which are environment specific (for example, > delivery to a logical mailbox or access to user information). ATM > mailets are coupled to basic service APIs defined by JAMES. IMHO it > would be better if mailets were decoupled by exposing their own API > interfaces rather than using JAMES service APIs. Yeah, and if you look in the sandbox there's one example of how this can be done. > i agree about extension points but it is the service APIs that worry me > > ATM mailets are coupled to service APIs. some of the service APIs are > reused as extension APIs (which IMHO is not a good idea). so mailets > are coupled to extension APIs which is IMHO not at all good. Agreed, we need to design generic service API's in MAILET which services need to expose for their primary purpose, but also have extension API's which expose management/lifecycle interfaces to allow contributed services to be managed by the container. d. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
