commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertdon...@mac.com>
Subject Re: [Vote] ARMI as Commons package
Date Wed, 09 Jan 2002 19:40:20 GMT

On Wednesday, January 9, 2002, at 05:19 PM, Paul Hammant wrote:

> Ted,
>
>> I believe that its possible that not enough of us understand the
>> background of the ARMI codebase.
>> There's a lot going on, and it can be helpful to spoonfeed us old,
>> feeble, and bandwith-challenged folk =:0)
>>
> Primarily it is an alterative to RMI.  It exports* method calls to other 
> processes.  It does not need to enforce inheritace of a base interface 
> (refer 'Remote') not tack on exceptions to the throws of each method 
> exported (refer 'RemoteException').  As such in can export 'normal' 
> interfaces.  Even one the original authors throught not remote accesible.
>   Now this is not my invention.  A buddy tells me that .NET has a 'hassle 
> free' method exporting feature.  Graham Glass did it first with Glue.  
> Glue is The-Mind-Electric's interface exporter over SOAP. It is truly 
> excellent stuff.  Incidentally Graham is the original author of the 
> legendary ObjectSpace Voyager app-server ( if anyone can remember back to 
> 96).
>
> * In the PROPOSAL.txt document in CVS, there are fuller details 
> especially the multiple transports.  The most useful is barely a 
> transport at all - it is a Pipe implementation that is of direct use to 
> Avalon (and probably nothing else) as it transport method calls between 
> classloader leaves in the same VM.
>
>> Given the other tidbits that have come up in this thread, I would now
>> toss my binding
>> +1
>>
> I understand that the move cannot happen before it's use anywhere. Given 
> that rule (which is fair I guess) I might be inclined to stay here. 
> However I suspect I will be voted down at any stage, because people just 
> plain do not see the need.  This makes me feel essentially unwelcome and 
> that I should just go back to Avalon where I am welcome.
>
>> It's important to understand that the sandbox is open to any Jakarta
>> committer, and it's helpful to make an actual proposal, as detailed in
>> the Commons charter, so that we know what's what.
>>
>> If the component is also going to be useful to the Avalon codebase, then
>> I would say it has a high potential of being supported in the longterm,
>> and would be a welcome addition.
>>
> Thanks for taking time to pen a weighty reply.  I am still unsure whether 
> I am wasting my time here... There have been 100 postings on politics and 
> 10 on AltRMI (nee ARMI), mostly just me talking to myself or defending a 
> position.  This group is way more political than Avalon. Anyway, thanks 
> for the lengthy and concilliatory reply - you're a worthy Apache dude. 
> Peace n Love n all that....

i'm sorry that you feel this way.

the problem is that here in the commons everything takes much longer. IMHO 
it's not so much that the commons is political - it's more a case of 
people trying to figure out how the commons can be made to work 
effectively. we'll all still learning here - and that is often noisy and 
sometimes painful.

i really would have liked to have the chance to take a look at ARMI and to 
make a few comments (even if i ended up only saying "well done") before i 
cast my vote but i really haven't had the time. (i think of casting a +1 
for a new sub project as meaning that i'm willing to undertake basic 
project maintenance and field user questions when there's no one else who'
s more able available.)

you've been pretty active and i certainly think you've got the energy to 
push forward a solo project but i'd feel much happier if ARMI had one or 
two more committers who are willing and able to field questions about ARMI 
and who you're happy about reviewing and committing patches when you're 
not around.

i also agree with scott's point that choosing a new name should have come 
before pushing for the commons vote.

"more haste, less speed"

<sigh> +1 </sigh>

- robert


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message