Stefano Mazzocchi wrote:
>
>Of course, the best thing would be for A5 to resurrect the separation
>between 'blocks' and 'components' as I stated previously. That would
>solve all problems
>
Lets take it just a tiny little step further because I happen to have
been working on just the subject (let's call it a coincidence). Based
on a lot of emails it appears to me that there is a potential reference
point that "could" be shared by the majority (wow, I'm getting
adventurous - perhaps this isn't going to be such a little step after all):
A Policy Statement:
-------------------
1. restrictions over and above the "freedom" and "liberty" that user's
have grown to love and respect shall not be retracted
[i.e. words such as "freedom", "liberty" and "abuse" all reflect a
differential between the informal and formal models of usage.
That differential has been established and cannot be resided.]
2. recognizing that, there is potential for restructuring, adaptation and
migration on a premise of "more gain than pain"
[i.e. we all want to move forward and it is recognized that this
may involve changes in practices, approaches, and ownership over time
but the common denominator is the existence of a mutual value
proposition]
3. whilst recognizing and respecting the overriding precept of a
framework grounded on the mandate of delivering, maintaining and
evolving a component framework supporting development, deployment,
execution and reuse.
[i.e. that within core of Avalon there are some things that are
sacred, things that touch at the very integrity of the platform,
and these things must not be compromised]
The above policy statement was prepared with a reasonable degree of care
in the selection of words, the implications therein and the emphasis
assigned. There is a clearly identified and healthy conflict of
interest between point (1) and (3) and the context and rules of
collaboration identified under point (2). Why put this into words - to
capture the value around the table. Because the next phase in Avalon
evolution involves solutions that will capture and engage (1) through
engineering solutions from (3) via active and engage activity in (2).
A Strategy Statement:
---------------------
To get the point of this whole thread - "the need for hints".
Isn't this a question of SOC?
Avalon Container Avalon Client
Architecture Architecture
|----------------| |----------------| |----------------|
| integrity |<--->| knowledge |<--->| simplicity |
| reuse | | practices | | usability |
| portability | | context | | efficiency |
| security | | | | consistency |
| scalability | | | | |
| reliability | | | | |
|----------------| |----------------| |----------------|
Providing there is framework for the introduction domain knowledge,
practices (good and bad) and application context between the
formal-component-container-abstraction and a less constrained client
abstraction, we have a management context with which to deliver a
spectrum of component management solutions that embrace a common and
sustainable architectural framework - a.k.a. the foward-looking strategy
for A4.2...A4.X, A5?
Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
