james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: Not Mine
Date Thu, 19 Nov 2009 08:44:01 GMT

Sorry for being pragmatic, but your framework will have to deal with
this comments if you want to start telling "our framework" instead of
"my framework".

If the framework needs so much text to be explained then it will
probably be not good for James. We need something that people already
know, or alternatively something that people is able to grasp without
reading pages of docs. Maybe you want to try with concrete examples,
diagrams, but not so much text. I admin I read all you wrote and I
still don't understand how your framework works. Bad thing.

You propose a new container framework using interfaces to be
implemented. in 2009 this is a bad practice, currently frameworks use
@annotations, AOP, agnostic (pojo) dependency injection. If we want an
interface based framework then Avalon does a damn good job here,

You also will need a good understanding of other frameworks so to
publish a comparison and use common terms defining what makes your
framework special. What is the most similar framework around, what
does your framework do better? Does your framework try to solve
container issues (class loading, component isolation,
componentreloading, deployment) or application assembly (dependency
injection, component configuration, service discovery/linking,


2009/11/18 Simon Funnell <simonfunnell@googlemail.com>:
> Hi,
> By the way, its only 'my' framework by virtue of the fact there is no 'our'
> to refer to. I could probably refer to it as 'the' framework with you being
> able to infer what I am referring to from experience, but its actually
> called 'Platformed' and I intend to make it open source. Also, after some
> research and reflection, I actually think its much more suitable (it was
> designed for this purpose). There is no escaping some of the differences in
> approach however. I am quite willing to invest some time implementing some
> things which you can take a look at, it really wouldn't take to long to
> modify some existing code. Avalon defines interfaces such as Loggable(?) but
> there is no equivalent concept with what I am doing because all things are
> inherently loggable, components do have to be built in a way that enables
> loggability (and lots of other things) though. It basically means breaking
> down some of the existing code into smaller chunks that can pieced together.
> These smaller chunks could be recomposed into an alternative implementation
> of existing classes and I could also use these smaller chunks in a different
> arrangement. As I say, I could implement an example which would allow people
> to make an evaluation about any sort of decision or what not.
> I think you might actually like it, it was written a while ago and its only
> by looking at it closely again that I remembered how much work I put into
> it. My last email didn't accurately reflect the whole architecture, the
> micro virtual machines I have touched on are extensible through
> 'operations'. Current James classes have methods such as initialize,
> service, destroy etc, I would have to replace these methods with actual
> classes (which implement an interface called Operation). Operations are
> stateless instances that implement functionality, micro virtual machines
> provide the operations with a context upon which to operate. Different micro
> virtual machines can have contexts like application/session etc depending on
> what's required. If you wanted to log the state of any given machine, at any
> stage, you just plug in a logging operation at the necessary place. This can
> be done dynamically, like for example an individual client matching some
> criteria. The smaller things are, the more reusable they are. I could very
> easily create an adapter that takes existing mailet/matchers and transforms
> them into Operations for  micro virtual machines processing the spool.
> I've probably said too much/too little so I wont post again until I get some
> feed back, or have something working, which ever comes first. I am still
> interested in producing some documentation as well, suggestions are welcome.
> Thanks,
> Simon
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org

To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message