Purity

[Simon Funnell <si...@googlemail.com>]

Hi,

Thanks for the comments. I realise that what I am pointing out is not 
straight forward, but I think I do have some insight in how to achieve 
it. If I am really honest the current object orientated paradigm is 
flawed and this flaw propagates to all software based on certain 
principles espoused, ideally we want to be modelling the relationships 
between objects as opposed the objects themselves, then infer a given 
objects properties from its relationships, something that cannot be said 
of the inverse....but this is a little too deep. That type of thinking 
however has allowed me to look at the problem slightly differently.

Briefly, the framework I have been developing is aimed at users that 
require sophisticated combinations of services and features but have low 
levels of traffic. A typical user would be a small business professional 
with one physical machine hosted 24/7 that provides a 'virtual office' 
with website and email server, software components will share common 
business objects and all the usual. These professionals may recruit the 
services of various technical skills sets 
(artists,designers,developers,etc) from time to time who will need 
access to the things they are responsible for.  This means my focus is 
on manageability and integration instead of scalable capacity at 
present, but I hope to move to that in the future. My framework is not a 
lot different to other frameworks in principle but there are subtleties 
which distinguish it from others. Also, the terminology I have used to 
represent certain concepts is generally more descriptive of what it 
actually does in comparison to others, this makes it easy to understand 
for both new and more experienced users. Although I am happy with what I 
have so far the thing stopping me from finishing it is the component 
model. For instance, my framework could actually support James, but not 
in the way I would like. I am loath to start working on something when 
there are other frameworks that already do it very well. I have been 
influenced by a few other frameworks with Avalon being probably my first 
exposure to the idea of a framework many years ago. I guess I am at a 
critical design juncture and the perspective of others will be useful at 
present.

Anyway, I think it is generally fair to say that James is a component, 
composed of components that are composed of components and so on. 
Components generally have a life cycle and have relationships with other 
components. And that last bit is important, a component has 
relationships with other components. Usually, when initialising a 
component, a framework will be responsible for supplying other 
components that the component being initialised requires to operate. At 
a very low level, we take an object and put other objects inside of it. 
This is what needs to change (conceptually at least). Another way to 
look at it is that when we initialise a component, we do not pass it the 
other components it requires to operate, instead we pass in a set of 
relationships. This is very like the idea of an interface but slightly 
different.

That is a bit abstract so I will use the terminology from my design. In 
my framework, every component is a 'micro virtual machine' and 
applications/components are networks of these machines. When a component 
is initialised it is passed a network, or collection of network cards if 
you like, that represent the components the component being initialised 
requires to operate. This means the usual parent/child relationship 
between components exists but is virtual instead of real. Now, when a 
given component calls the method of a sub-component (virtually a child, 
but really a peer) it is actually sending a message to another component 
(method calls here are paths/expressions....). This now gives the 
framework an opportunity to intercept the before and after of the call 
and evaluate its properties for monitoring, applying security measures 
or other such things. This interception can be very fine grained and is 
completely transparent. In this way all components communicate in a 
uniform fashion and permit the emergence of self-organising systems (or 
if that's too much, having the ability to drop a component into a system 
and have it adopt the policies of the system without configuration(in 
principle)).

I haven't touched too much on implementation details because they are a 
few consequences of this design (which I think are great, but may not 
sit well with other programming habits). If you can really grasp what I 
am saying it is actually moving towards what I said right at the 
beginning, i.e. focusing a bit more on the relationships of objects 
rather than just the objects themselves. Object orientated paradigms are 
good for describing objects in abstract space, but are insufficient for 
describing the effects of time because the effects of time are inherited 
from the system within which an instance of the object manifests.

That is a summary of my approach and as you can probably tell it 
requires a very specific method of component design hence questioning 
its immediate practicality. That said, I still think it is worth solving 
the problem because its already halved solved and the benefits are 
obvious. I will leave it here to get some feed back, I do have more to 
say on the subject.

On a side note, if there is anything specific about the documentation 
you would like looking at, I can take a look and see if I can help. As I 
am using James at the moment so its operation is personally more 
important than its development (in that my current position requires 
it). In this way, if I can improve the documentation, this in turn will 
improve the user base and I will benefit from the impact of a broader 
community.

I hope you find this is of interest and look forward to any suggestions.

Regards,

Simon


















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