On Thu, 24 Oct 2002, Scott Sanders wrote:
> On Thu, Oct 24, 2002 at 09:28:11PM +0100, Stephen Colebourne 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? > > > > Why not 3) concern areas, like your mailing list suggestions: xml > serialization, http clients, language libraries (the biggest thing > that is missing in most languages), etc? I think if we're to try and think as A-Cers and not J-Cers, this makes the most sense. My instinct is that language libraries [like Stephen I'm predominately interested in this] will not share much, but then I think about it a bit. C and Java will share very little, however C# and Java will pratically clone each other. In fact C# Commons should be whispering to Java Commons about things in the C#-SDK and vice-versa. Same for other Java-like libraries. Equally, when templates are added to Java in 1.5 [hopefully], the C++ Commons ought to be able to step in with a lot of ideas already. So I'm warming to the idea of cross-language community. When I thought of it as C and Java it was just too extreme, but if I hypothesis new languages at Apache then it makes more interesting sense. > > This affects many things - how the mailing lists are structured, how the > > website is structured, how the communities will form, etc. > > > > I would like to see some clarification on this. The key aspect to me seems > > to be the mailing list one: > > > > Does it help to have C/C#/D/Perl/PHP/Java components on a shared mailing > > list? > > IMHO it does from the standpoint that for instance, NTLM > authentication affects both serf and httpclient, and I have seen > myself learning things from those people well-versed in other > languages on algorithms and such. Matrix of mail lists. Language and functionality group. Of course that brings in the wonder of cross-posting... hmm :) Maybe James could help out here? I'd mail to [EMAIL PROTECTED] and it'd goto [EMAIL PROTECTED] and [EMAIL PROTECTED] ? I guess a normal mail server could do it actually. > > Or is per language better? -0.9 I would rather see no division > (first preference), or a division not along language boundaries. > But, then again, I might just be smoking the really good fairy dust :) I'd like some of that fairy crack. But I'm also not sure if language boundaries hurts or improves. Will just have to try it. It does mean opening ASF up to lots of new things. ie) A language-agnostic commons is worthless if the chief languages are C and Java. We need to fill the spectrum in rather than just have the ones at each end. > > For example new mailing list groups could be formed along these lines: > > a) Collections, IO, Lang, Pattern, Util, BeanUtils components from j-c (a > > 'Java core' list) > > b) Betwixt, Digester from j-c, and components from XML-Commons (an 'XML' > > list) > > c) HttpClient and Net from j-c (a 'Networking' list) > > d) Catch all for smaller components and the sandbox > > (please don't debate the details of which component is in which (yet), its > > an example!) > > This is a pretty good idea, IMHO. Just throw the language-agnostic > stuff in, and you are good to go :) +1. I like this idea. Network. Library. XML. (and then DB. GUI. etc) There's also the fact that we might want to use Categories within a project. ie) Apache-Commons is a top level project which contains a Java Category and a Language-Library Category. However, although Commons Lang belongs to these, it also belongs to Apache Jakarta-Core category which is a federation of Lang/IO/Collection etc, this categories sole job being to produce a unified jar, etc etc. Hen
