Peter Donald wrote:
> At 12:07 PM 6/13/2002 +0200, you wrote:
> LET ME MAKE THIS REAL CLEAR,
>
>> I WANT TO KNOW WHY "org.apache.Thing/key" is any different to
>> "something" in the context of a component lookup key value.
>
>
> Because everyone but you follow the first convention.
I know, but it's tough when your leading a Renaissance
... truth, discovery, understanding, reality, delivery, progress -
someone has to take the lead.
:-)
> Thats the main reason.
I can live that because the convention is completely unqualified.
There convention delivers an apparent fix - but in reality, the
convention only solves 80% of the question and remaining 20%^ is throw
into a basket called learning cure. I may be the only one here concerned
with the scaling down of the leaning curve - but that's something I'm
happy living with - in my old age I'll look back and smile.
> You can choose to follow our conventions or not - depends on how
> widely used you want your components to be ;)
Its more that that.
Today, my number 1 priority is to deliver maintainable and manageable
solutions for global service management. What this entails is the
delivery of a platform that is easy to maintain. Phoenix stacks up as a
very good computational solution for the problems I'm dealing with (a
really complex array of services, dependencies, local versus remote,
etc.). But Phoenix is too hard for the sort of customer who want's what
I have. I would end up doing site visits to fix their systems with minor
errors in assembly.xml or config.xml. That means time and effort from
both me, my team, and my customer. My preoccupation is that a large
degree of this is redundant - the errors are actually introduced by the
user because the platform is forcing the user to declare too much. The
anti-Christ in this situation is a platform that only raised an issue if
there is an issue to raise. The smaller the user intervention, the
smaller the cost of user support, and a commensurate increase in the
bottom line. If your personally covering a bottom line you will
understand what I'm talking about. Why am I mentioning Phoenix here -
because Phoenix is backed by a great implementation and a lot of
documentation. And yet there are issue with usability. That's not a
complaint - its an observant focussed on my needs as a user of Avalon
-more is need, more flexibility, more integrity.
>
> In 99% of cases you don't need they "/key" postfix. And thus reasons
> being;
The Avalon component model gives me integrity withikn a qualified scope
- we are only just starting to explore the ECM question. In this process
comes practices that are banded about as recommendations that in all
honesty should be classified as workarounds for interoperabilty issues
that will probably sole 99% of the cases. In the 1% that occur, and my
team have to try to track down the issue and days later they confirmed
to me that's its an undocumented 1% situation which should never happen.
So the team have the responsibity of fixing this. The budget they are
working on is the margin from the over 99 customers that by chance have
not encountered this problem to-date. Every day that they spend on the
problem costs me the margin I gain from 4.3 customers. If you want to
get to the issue - its two things - firstly, ECM has an computational
contract with its components that is at best badly documented and even
worse, the second issue - hidding behind phrase of "beastpractive" and
"recommendation".
>
> * automagically maintained. ie if you change the package of service
> interface you don't have to worry that you forgot to update the ROLE
> string.
seperate concern - nothing to do with the lookup operation semantics.
>
> * You can reuse the ROLE string in interface across multiple consumers
> without worrying about name clashes.
Fudge.
The role string is semantically significant when passed to ECM. Yes, if
you declared public static final String ECM_ROLE I would agree. If a
convention were introduced from the declaration of a public static final
Version VERSION in an interface I would +1 it immeiately and push for
its escalation to the level of a real "best-practive". If I want the the
class name of an iterface I can use <classname>.class and I know a
compiler error will tell me if something is wrong.
>
> * don't need to worry about maintaining <role> in dependency for
> component as it is auto maintained for you
> etc.
Which falls back to the interface != service scenario.
The role name that Merlin deals with (and Phonix) is linked to a service
which is interface and version. If the recommendation was clear and
precision about the defintion of a service interface (via a static
declaration) then I'm starting to move to your position.
> Anyways most containers require or at least show a preference for the
> pattern and it has been a fairly established pattern.
Established, but unqualifed and incomplete.
Its correctable, but its also BAD, just plain but bad bad.
> Why not save yourself the extra work and follow suite? Maintaining
> role strings in 4 difference places and remembering to change them
> when you move the interface is something you can do if you want. Don't
> expect anyone else to feel sympathy for you though ;)
Trust me - I'm saving myself extra work by ensuring that my sytems work
in 100% of post validation cases. 99% is just not good enough.
Cheers, 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]>
