On Thursday, October 24, 2002, at 10:05 PM, Justin Erenkrantz wrote:
--On Thursday, October 24, 2002 9:28 PM +0100 Stephen Colebourne <[EMAIL PROTECTED]> wrote:
2) One sub-project for each component ignoring language (eg. commons.apache.org/collections). But then what happens if that component is implemented in two languages?
IMHO, it would then be up to the component to create divisions internally based on language.
That is:
commons/httpclient
could initiallty start out with the codebase from apr-serf. If the httpclient from Jakarta wants to come over, then the serf committers and the httpclient committers can duke it out. But, the httpclient is their collective place to play. It's their responsibility to sort out the code divisions. (I would probably suggest commons/httpclient/serf, commons/httpclient/java, but I don't really care to think about it until it happens.)
from my experience in jakarta-commons, i'd say that small, focused components are the way to go.
therefore, i'd prefer to see each component language specific and managed as a separate releasable unit. so, in this case, i think that the java and c versions of httpclient should exist as separate components which can have their own release cycles etc.
in terms of namespaces, i think here jakarta (and the other maybe-federations) could be used to our advantage. if the java version is namespaced jakarta-httpclient then there would be no confusion with apr-httpclient (or serf-httpclient).
- robert
