Mailing-List: contact dev-help@community.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@community.apache.org
Received-SPF: pass (nike.apache.org: local policy)
From: "Mattmann, Chris A (388J)" <chris.a.mattmann@jpl.nasa.gov>
To: "dev@community.apache.org" <dev@community.apache.org>,
        "dennis.hamilton@acm.org" <dennis.hamilton@acm.org>
Date: Thu, 29 Dec 2011 20:59:03 -0800
Subject: Re: Apache Extras Question
Thread-Topic: Apache Extras Question
Thread-Index: AczGr2PxYSzMdluWRC+aKlSmlFj5Gg==
Message-ID: <31EB91E3-CE8D-4E74-9F52-0DCC6BF0624D@jpl.nasa.gov>
References: <DD9692BD-1E27-45A8-8E80-6E42B6DA779E@jpl.nasa.gov>
 <CAM1yOjZHayPvdS=624xdKej3YMBXphTJCAFsVFNjUWNye0quZQ@mail.gmail.com>
 <15F56445-F5E3-4EBB-BAE4-71A7B973F294@jpl.nasa.gov>
 <CAM1yOjZqYUVv-KoivU4zdnVbozrt02MUCeLr=D3d9ebX1g-_oA@mail.gmail.com>
 <8D8C4302-AD75-4AD6-990A-DAAB6098C9E2@jpl.nasa.gov>
 <002501ccc666$5a3c8020$0eb58060$@acm.org>
 <DFC3FB12-98F6-46DC-8B86-1205BD1301B7@jpl.nasa.gov>
 <003501ccc66c$caa94400$5ffbcc00$@acm.org>
 <10F7EB13-FA75-4F5B-B7BC-F0445EAE99EB@jpl.nasa.gov>
 <002f01ccc696$32fff110$98ffd330$@acm.org>
In-Reply-To: <002f01ccc696$32fff110$98ffd330$@acm.org>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Hi Dennis,

On Dec 29, 2011, at 5:56 PM, Dennis E. Hamilton wrote:

> Funny, your conclusion is exactly contrary to my reasoning. =20
>=20
> It strikes me that you are talking about extending the decentralized gove=
rnance of the org.apache.oodt.* namespace (i.e., the ability to add branche=
s and new types) to an external effort that, coincidentally, happens to be =
conducted by a member of the Apache OODT project and not within the structu=
re of the project itself.

No, that's not what I'm proposing. I'm proposing to use Apache Extras, a su=
pposedly sanctioned
"associated" and not "external" effort that supposedly is amenable (per its=
 own explanation page
that I've cited several times and won't bother doing again) to libraries an=
d licenses outside of=20
the normal ALv2 process to host closely related Apache OODT code there and =
to leverage=20
the org.apache.oodt namespace as part of it.

Mark Struberg had another concrete suggestion: kudos to him for proposing u=
sing=20
org.apachextras.oodt (implied). I could live with that, but don't believe I=
 (or anyone else)
should have to.

>=20
> It is ok for you to have a plugin there.  And you can certainly use org.a=
pache.oodt.* types in the manner in which they are established by Apache OO=
DT.=20

I'm not even sure what you're saying in terms of using "org.apache.oodt.* t=
ypes". If you mean=20
using "interfaces" published by the org.apache.oodt namespace, then yes, I =
agree. The plugins=20
that I'm talking about are concrete Java class implementations of the OODT =
CAS PushPull Protocol=20
interface.=20

>=20
> I just don't think the ability to expand the namespace travels so easily.=
  Would you grant the same capability to someone who had no affiliation wit=
h the Apache OODT project?

I'd rather not talk about hypotheticals (kudos to Sam Ruby for teaching me =
that) and focus instead
on what I'm actually proposing.=20

Cheers,
Chris

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW:   http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++