james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Funnell <simonfunn...@googlemail.com>
Subject Re: Not Mine
Date Thu, 19 Nov 2009 12:42:18 GMT

I will pose it as a 'user' request, this should clarify things:

Can James be designed in a way that allows it to be deployed in both 
legacy and next generation frameworks?

Next generation frameworks attempt to address issues such as declarative 
logging and the like ;)



Stefano Bagnara wrote:
> Simon,
> 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,
> already.
> 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,
> configuration)?
> Stefano
> 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

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

View raw message