Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Message-ID: <3F6F599A.3090002@apache.org>
Date: Mon, 22 Sep 2003 22:20:42 +0200
From: Stephen McConnell <mcconnell@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624
MIME-Version: 1.0
To: general@incubator.apache.org
Subject: Re: [PROPOSAL] PMC Vote to incubate Directory Project
References: <NBBBJGEAGJAKLIDBKJOPCELCEDAB.noel@devtech.com>
 <3F6F53E6.9010302@steitz.com>
In-Reply-To: <3F6F53E6.9010302@steitz.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


Phil Steitz wrote:

> See comments inline
>
> Noel J. Bergman wrote:
>
>>> I have no problem with protocol-centric projects, and no problem with
>>> language-centric projects, but I do have a problem with 
>>> protocol-centric
>>> projects that assume one implementation language is "best".
>>
>>
>>
>> OK, I've seen enough language wars to understand your a priori concern.
>> Mind you, not everyone who uses Java is a language zealot.
>>
>>
>>> So, if the project is going to be language-agnostic, then
>>> I want that written into the charter and growth anticipated.
>>
>>
>>
>> We tried to anticipate this issue when preparing the proposal, and did
>> intentionally focus on the problem domain, rather than the platform,
>> excepting where the platform permitted *additional* synergies with other
>> projects (code sharing and embedding with related Java projects).
>> Apparently we did not do it sufficiently, but the intent is there, as 
>> is the
>> willingness to resolve the matter.
>
>
> The dodgy bit is defining what is core and what is not. See below.
>
>>
>>
>>> If someone else comes to Apache and says they want to start
>>> an LDAP server project using, for example, the Netscape code
>>> base (C++, I think) and another comes in wanting to establish
>>> a Python library for builtin calls to LDAP, should the ASF
>>> direct those projects to this same group or to their own projects?
>>
>>
>>
>> Aren't Xerces-[C|J] and Xalan-[J|C] under the XML banner?  Not being a
>> member of those projects, I'd appreciate hearing the experiences of 
>> those
>> who are, and from their PMC.
>>
>> Yes, I can see the potential of possibly growing too big for proper
>> oversight, and needing to split out, leaving the language-agnostic 
>> items in
>> the language-agnostic location.  But, in a sense, haven't those things
>> already happened, as projects were refactored from Jakarta to XML to
>> elsewhere (e.g., their own TLP or Web Services)?
>>
>> On the other hand, when(if) matured to TLP status, I'd imagine that 
>> there
>> would be some infrastructure related to particular implementations, and
>> parts related to all sorts of portable issues, such as schema, RFCs, 
>> ASN,
>> protocol testing, etc., that are common ground.  And, quite honestly, 
>> I do
>> not see that type of collaboration happening if the semantic domain 
>> isn't
>> given a home.
>
>
> I don't think that we have really answered Roy's question, but digging 
> into what exactly we mean by the "semantic domain" is a step in the 
> right direction. The "easy" answer is that the semantic domain equals 
> LDAP-exposed directory services, which is fully specification-driven, 
> platform- and language independent, etc; but the project already 
> includes more than that.
>
> We should ask ourselves if we expect to provide a home for extended 
> Perl, C or whatever APIs, naming services for those languages, etc.  
> If the answer is "yes", then fine, we can all agree and move forward.  
> If the answer is no, however, I agree with Roy that we should 
> acknowledge the scope limitation.
>
> FWIW, my opinion is that standards-based Directory + Identity services 
> could make up a natural "semantic domain" (actually more natural than 
> "XML") and we should focus on defining this domain, rather than what 
> languages or language-specific extensions will be supported (much as 
> that diminishes the importance of JNDI and the extended Java APIs that 
> I am personally looking forward to ;-)). Then we need to make the 
> explicit commitment that the core solutions implemented and the 
> eventual TLP will support *all* languages and *all* computing 
> platforms. Can we all agree to this? 


I would agree that the *scope* of the eventual TLP is multi-platform and 
multi-language.  The words "will support" are a subject of inevitable 
community development and contributions.

Stephen.

>
>
> Phil
>
>>
>>     --- Noel
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org