Howard wrote:

> 3) Chuck it over to Avalon

> I've looked to see how we could graft HiveMind into Avalon and
> but they are really quite different beasts.  The type-1 > vs.
> split is intrinsic and difficult to reconcile.  HiveMind's concept of a
> doesn't map so easily into the  Avalon space, and HiveMind's free-for-all
> approach doesn't jive with Avalon's dogmatic security model
> (including its explicit application construction descriptor).

I didn't mean to suggest that you should try to move avalon architecture
towards hivemind or vice versa,
but I did wonder if there would be support @avalon for an alternative
approach as an avalon sub-project.

The danger of having an Avalon alternative @jakarta is that it will be seen
by people as somehow being Jakarta's favoured solution, rather than as one
of two (or more) alternatives promoted by Avalon.
If you see what I mean.

Of course you went through this whole debate when we discussed whether we
needed Tapestry as an alternative to Struts, as equal members of Jakarta
neither approach can be seen to be in any way an "endorsed" or
"favourite". The same (IMO) would not be true for service frameworks if
Hivemind was a Jakarta project not an Avalon one. Hivemind would be seen by
some to be Jakarta's favoured solution.

FWIW I'm certainly not going to oppose this, Hivemind seems to be a well
thought out proposal, but I don't want Jakarta to be accused of trying to
replace Avalon, and I guess that will mean involving Avalon folks in the

Imagine the reaction there would be if I proposed a "make" utility as a
Jakarta sub-project, and perhaps you'll get the thrust of my concern.


The information in this e-mail is confidential and for use by the addressee(s) only. 
If you are not the intended recipient (or responsible for delivery of the message to 
the intended recipient) please notify us immediately on 0141 306 2050 and delete the 
message from your computer. You may not copy or forward it or use or disclose its 
contents to any other person. As Internet communications are capable of data 
corruption Student Loans Company Limited does not accept any  responsibility for 
changes made to this message after it was sent. For this reason it may be 
inappropriate to rely on advice or opinions contained in an e-mail without obtaining 
written confirmation of it. Neither Student Loans Company Limited or the sender 
accepts any liability or responsibility for viruses as it is your responsibility to 
scan attachments (if any). Opinions and views expressed in this e-mail are those of 
the sender and may not reflect the opinions and views of The Student Loans Company 

This footnote also confirms that this email message has been swept for the presence of 
computer viruses.


To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to