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?
Phil
--- Noel
--------------------------------------------------------------------- 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]
