On Feb 2, 2008 3:57 PM, Danny Angus <[EMAIL PROTECTED]> wrote:
> 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.
as stefano demonstrated, there's a critical mass of mailets which
could be moved immediately
> > 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,
JMS ->JNDI ...?
> 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.
i've been wondering whether it might be better to use a general
concept of a destination URL (rather than explicitly storing a mail).
some illustrations:
deliver("mailbox://[EMAIL PROTECTED]/~rob/INBOX") - deliver to rob's INBOX
on localhost
deliver("mailbox://[EMAIL PROTECTED]/~rob/alpha/beta") - deliver to rob's
alpha.beta mailbox
one advantage is that it would allow a single, simple interface to be
used for mailboxes, store, repositories. it would also open the door
towards easy interoperability with ESBs.
> There's also some
> design/modelling confusion in the area of users and accounts.
+1
may well be easier to understand and fix outside JAMES
> > 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.
IMHO it's important to comminicate this separation of concerns.
extension, service and management APIs are best factored out into
packages that communicate the design intention.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
