Great contribution! > -----Original Message----- > From: Leo Sutic [mailto:[EMAIL PROTECTED]
> > This is my suggestion: > > First, let's drop the "big container" approach. Just like "big > government" it puts a whole lot of functionality in the container > itself, and not in pluggable modules. +1 > > I want a small container microkernel that can be configured with: > +1 > + Component handlers (Appliances in Merlin) > > + Cross-cutting concerns (such as logging). Selectively > applied to different handlers/appliances. > Maybe it's only a "naming" question. I would like to see "Application Services" and "System Services" or something similar. The container is the "glue" between those services. The idea behind that is the question: for whom do we want to make the life easier? My answer to that: to the application developer! Maybe this distinction makes it easier to decide, which are "Component" functionalities and which are "cross-cutting concerns" By the way. I feel Merlin is already going that direction. > That's it. All the container should do is make sure > component A can get at its dependencies, and that the cross-cutting > concerns are applied. Nothing more. Everything else should > be factored out and made pluggable/ignorable. Right! > > Goal > ---- > Basically, is it possible to shrink the number of concepts > required to understand the container? How much? Again the question: who needs to understand what? The Application developer only needs to understand some fundamental terminologies/contracts: lifestyle and lifecycle, service/component assembling, transaction- and presentation- service. System Developers have to understand how they can apply functionalities to those contracts. Container developers have to understand, how to keep the contracts to both sides stable and simple. And that's the real challenge and magic. Maybe we have to start thinking about the kernel as a "double container" or a "sandwich container" which servers application services in one container and system services in an other. > > Let's see how much terminology we can throw on the scrap > heap. I'm convinced that really smart people such as ourselves > can describe really complex things using really simple > words. > +1 > Suppose we can say that "everything is either a X or Y". Then > we can define X and Y as interfaces, make them pluggable > and off we go. Let's go!! Andreas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
