Hi,
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 ;)
Regards,
Simon
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 <[email protected]>:
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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
