You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Ted Husted <hu...@apache.org> on 2002/01/09 17:36:17 UTC
Re: [Vote] ARMI as Commons package +1
Paul,
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)
Given the other tidbits that have come up in this thread, I would now
toss my binding
+1
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.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Building Java web applications with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/
Paul Hammant wrote:
>
> Folks,
>
> > 2) Take it back to excalibur and just shove it in (where it becomes a
> > tool amngst many that already have a community).
>
> Actually I don't think this is so rude after all. It is not like ARMI
> was commissioned or solicited for. I'll go back to where I came from,
> with the official vote being one for and one against.
>
> - Paul H
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Vote] ARMI as Commons package
Posted by robert burrell donkin <ro...@mac.com>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Vote] ARMI as Commons package +1
Posted by Paul Hammant <Pa...@yahoo.com>.
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....
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Vote] ARMI as Commons package +1
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 1/9/02 12:15 PM, "bayard@generationjava.com" <ba...@generationjava.com>
wrote:
> I'm a +1 on it being in Commons.
>
> It's an itch that sounds very generic and reusable. Seems a good commons
> to me. I think the only question is whether something should move from the
> sandbox to commons without really gaining much peer review/use.
>
> However, it sounds as though Avalon will have a dependency on it, in which
> case, should any Jakarta project that isn't in a sandbox be dependant on a
> sandboxed project?
That's up to them, isn't it? The upside is that it motivates them to send a
crew over to help out :)
>
> The Utils project in the sandbox is a project from which many projects
> grow, but it also has classes that belong in it. They're very usable but
> should other projects be dependent on them?
>
> It seems that the obvious solutions conflict with each other.
>
> Bay
>
> On Wed, 9 Jan 2002, Ted Husted wrote:
>
>> Paul,
>>
>> 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)
>>
>> Given the other tidbits that have come up in this thread, I would now
>> toss my binding
>>
>> +1
>>
>> 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.
>>
>> -- Ted Husted, Husted dot Com, Fairport NY USA.
>> -- Building Java web applications with Struts.
>> -- Tel +1 585 737-3463.
>> -- Web http://www.husted.com/struts/
>>
>>
>> Paul Hammant wrote:
>>>
>>> Folks,
>>>
>>>> 2) Take it back to excalibur and just shove it in (where it becomes a
>>>> tool amngst many that already have a community).
>>>
>>> Actually I don't think this is so rude after all. It is not like ARMI
>>> was commissioned or solicited for. I'll go back to where I came from,
>>> with the official vote being one for and one against.
>>>
>>> - Paul H
>>>
>>> --
>>> To unsubscribe, e-mail:
>>> <ma...@jakarta.apache.org>
>>> For additional commands, e-mail:
>>> <ma...@jakarta.apache.org>
>>
>> --
>> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>> For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
>>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"Now what do we do?"
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Vote] ARMI as Commons package +1
Posted by ba...@generationjava.com.
I'm a +1 on it being in Commons.
It's an itch that sounds very generic and reusable. Seems a good commons
to me. I think the only question is whether something should move from the
sandbox to commons without really gaining much peer review/use.
However, it sounds as though Avalon will have a dependency on it, in which
case, should any Jakarta project that isn't in a sandbox be dependant on a
sandboxed project?
The Utils project in the sandbox is a project from which many projects
grow, but it also has classes that belong in it. They're very usable but
should other projects be dependent on them?
It seems that the obvious solutions conflict with each other.
Bay
On Wed, 9 Jan 2002, Ted Husted wrote:
> Paul,
>
> 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)
>
> Given the other tidbits that have come up in this thread, I would now
> toss my binding
>
> +1
>
> 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.
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Building Java web applications with Struts.
> -- Tel +1 585 737-3463.
> -- Web http://www.husted.com/struts/
>
>
> Paul Hammant wrote:
> >
> > Folks,
> >
> > > 2) Take it back to excalibur and just shove it in (where it becomes a
> > > tool amngst many that already have a community).
> >
> > Actually I don't think this is so rude after all. It is not like ARMI
> > was commissioned or solicited for. I'll go back to where I came from,
> > with the official vote being one for and one against.
> >
> > - Paul H
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Vote] ARMI as Commons package +1
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 1/9/02 11:36 AM, "Ted Husted" <hu...@apache.org> wrote:
> Paul,
>
> 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)
>
> Given the other tidbits that have come up in this thread, I would now
> toss my binding
>
> +1
Ted - I have come to understand you as a stickler for rules and order (among
other positive qualities :)
A related thread is discussing the fact that the proposal doesn't even
satisfy the rules that you took the time to record for us and post...
>
> 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.
It's not 'helpful'. Isn't 'required' the word you are looking for?
> 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.
Yes - that I agree with.
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
You're going to end up getting pissed at your software
anyway, so you might as well not pay for it. Try Open Source.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>