>>> Emil Eifrem <[EMAIL PROTECTED]> 15-Apr-00 11:01:33 PM >>>
Aaron M. Renn wrote:
>>I think we do need to develop a policy standard for what packages
should
>>be included under the GNU namespace, and generally how that
namespace
>>should be subdivided. Most of the current packages that are under
>>the gnu.* namespace could (and probably should) be under the
domain
>>names of their developers.
I don't wholeheartedly agree with Aaron on this.
It has to be subdivided yes... but subdivided with some proper
organisation.
Emile wrote:
>For example, when I used the regexp package at work my colleagues
were
>constantly reminded that they worked with GNU software. Since they
typed
>'import gnu.regexp.*' all the time, I had a good opportunity to
introduce
>to them much of the GNU philosophy and stuff like the difference
between
>the GPL and LGPL, etc. I don't think it would've been the same if
regexp
>had been under 'com.somedeveloper.regexp' or whatever.
>Well anyways, it's just a thought. The real issue is really how to
properly
>subdivide and manage the packages under 'gnu.*'.
Subdivision by domain name of developer? That seems just as arbitary
as what we have now and it means that gnu Java code is "diluted" (as
Emil points out).
My recommendation is for us to setup various packages and hope that
people will follow them, for example:
- gnu.lang
for packages language and parser tools eg: some of the Kawa packages?
regexps?
- gnu.web
for packages relating to HTTP and so forth (eg: GNU-Paperclips
stuff)
- gnu.network
for stuff relating to mail
It really is a bit of a job. I'm happy to take it on but I would
rather proceed one step at a time, to build confidence (your
confidence of me as well as anything else) and not loose momentum
through over-reaching.
When it comes to Classpath they will the most freedom to define
package names because most of the work is implementation of the core
java.* packages.
In a perfect world I would suggest that all Classpath's gnu. stuff
went under a package:
gnu.javaimpl
but it's not a perfect world and they're working hard enough
already.
If the Classpath developers *want* to move I would be willing to do
all the work moving the code to the new namespace (cue discussions
about org.gnu) - I've got plenty of elsip hacking experience.
The only issue with Classpath package is that of course the rest of
us will have to steer clear of package names that Classpath have got.
If people are content to let me draw up a list of packages and start
badgering people to move things across then I will take on the task
and ensure that Classpath package names are not used.
Whilst we're talking about this though there is the issue of what we
do about the 2 competing GPLed java library implementations, ie:
Classpath and Kaffe. I asked Trasnvirtual about Classpath some time
ago and didn't get a satisfactory answer.
What is the GNU policy? to support Kaffe as the VM (sorry Japhar
peeps but that's what the site says) and Classpath as the API?
Is there anyway that we could work towards a single code base or is
there a fundamental problem?
Nic Ferrier
