J Aaron Farr wrote:
FYI:
I think someone wanted this to get forwarded to the Avalon 'general' mailing
list, but since that doesn't exist, I thought I'd send it to our dev list.
For the Avaloners:
There's been a bit of discussion lately on [EMAIL PROTECTED] about what to do with
Hivemind seeing that it has started to outgrow its current location in
commons-sandbox. Some have suggested that it fits better over here in Avalon
(as a sub-project) than in Jakarta. In some respects, I agree. I think its a
little light to be its own top-level project (hivemind.apache.org) and if you
look at the jakarta charters vs avalon charters, Hivemind falls more on the
Avalon side of things. Not sure what Howards thoughts are on that.
Hmm. The thing is if it is "chucked over here", the whole Hivemind approach
will be factored toward the way we are doing things. We only have so many
developers, and supporting something like this would be kind of a strain on our
resources.
Have the IP issues been sorted out with this package? There are a whole host
of questions that we would need to sort out, PMC to PMC. In the interest of
fairness, I think we should seriously talk about that in that capacity. We
would, of course, include Howard in on the conversation.
--- Danny Angus <[EMAIL PROTECTED]> wrote:
Howard wrote:
3) Chuck it over to Avalon
I've looked to see how we could graft HiveMind into Avalon and vice-versa,
but they are really quite different beasts. The type-1 > vs. type-2/type-3
split is intrinsic and difficult to reconcile. HiveMind's concept of a
module 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
discussion.
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.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
jaaron <http://jadetower.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
