On Fri, Oct 01, 1999 at 10:14:00AM +0200, Stephane Bortzmeyer wrote:
> > This is exactly analogous to, say, the selection of thread implementations
> > for glibc 2.0. You are still free to use some other thread model if you care
> > to, but the default one that most people write to is the one in gl
On Thursday 30 September 1999, at 10 h 30, the keyboard of "Ean R .
Schuessler" <[EMAIL PROTECTED]> wrote:
> This is exactly analogous to, say, the selection of thread implementations
> for glibc 2.0. You are still free to use some other thread model if you care
> to, but the default one that mos
On Thu, Sep 30, 1999 at 09:51:55AM +0200, Stephane Bortzmeyer wrote:
> The main strength of the current approach is that it allows two different
> implementations of SAX to live together, letting the user chose. Doing
> otherwise would mean having a form of arbitration, to decide which one will
On Wednesday 29 September 1999, at 12 h 0, the keyboard of "Ean R .
Schuessler" <[EMAIL PROTECTED]> wrote:
> a common library by organization. Let's say that you are writing an XML
> program and are using classes from several different organizations. Having
> to deal with classes coming out of: c
> From: "Ean R . Schuessler" <[EMAIL PROTECTED]>
..
> The thing is, even Sun doesn't follow their
> own policy when it comes to most of the libraries. There is almost nothing
> that is packaged under com.sun.* and the things that are you are advised
> not to use.
>
..
> Again, Sun created a sen
On Wed, Sep 29, 1999 at 01:28:01PM -0400, Seth M. Landsman wrote:
> Yes and no. Sun has defined the API, which goes under java.* and
> the extended api, which goes under javax.*. However, they do define
> com.sun classes and net.jini classes, which do follow their definition.
> I've f
Okay, having said this won't be a debian requirement, I'm much
more comfortable discussing this at its merits, instead of arguing against
unnecessary incompatibility.
On Wed, Sep 29, 1999 at 12:00:13PM -0500, Ean R . Schuessler wrote:
> On Wed, Sep 29, 1999 at 01:08:22PM -0400, Seth M. Lan
On Wed, Sep 29, 1999 at 01:08:22PM -0400, Seth M. Landsman wrote:
> However, are programmers who write this software going to be
> willing to do this? I can't see gnu going with gpl.gnu and lgpl.gnu as
> their top level, nor can I see mozilla willing change to mpl.mozilla with
> all of their
On Wed, Sep 29, 1999 at 11:39:51AM -0500, Ean R . Schuessler wrote:
> On Wed, Sep 29, 1999 at 10:58:53AM -0400, Seth M. Landsman wrote:
> > Umm, please don't. This would be wonderful if all systems were
> > debian and hetrogenius. However, what happens when I try to use my
> > software on a m
On Wed, Sep 29, 1999 at 10:58:53AM -0400, Seth M. Landsman wrote:
> Umm, please don't. This would be wonderful if all systems were
> debian and hetrogenius. However, what happens when I try to use my
> software on a machine that isn't debian, like I do on a daily basis. This
> would make j
> Instead of org.gnu.regex.Regex you might have lgpl.regex.Regex. The
> nice thing being that you wouldn't see anything in lgpl.* linking in
> something from gpl.*, because that would break the license. There are
> some disadvantages, obviously, but the process of linking is tightly
> coupled with
On Tuesday 28 September 1999, at 12 h 12, the keyboard of "Ean R . Schuessler"
<[EMAIL PROTECTED]> wrote:
> One of the irritating things about the Java packaging scheme is that you
> get this functional disassociation because of the organizational boundries.
>
> In other words, you have:
>
> ne
> On Tue, 28 Sep 1999 22:27:51 -0500, "Ean R . Schuessler" <[EMAIL
> PROTECTED]> said:
Ean> On Tue, Sep 28, 1999 at 07:37:12PM -0400, James LewisMoss wrote:
>> What if I want to release a regex package under the lgpl. Should
>> I have to rename mine so that it doesn't conflict with gn
On Tue, Sep 28, 1999 at 07:37:12PM -0400, James LewisMoss wrote:
> What if I want to release a regex package under the lgpl. Should I
> have to rename mine so that it doesn't conflict with gnu's? This
> seems like it would place a large burden on different organizations
> not to step on each othe
> On Tue, 28 Sep 1999 12:12:44 -0500, "Ean R . Schuessler" <[EMAIL
> PROTECTED]> said:
Ean> Instead of org.gnu.regex.Regex you might have
Ean> lgpl.regex.Regex. The nice thing being that you wouldn't see
Ean> anything in lgpl.* linking in something from gpl.*, because that
Ean> would
Here is an idea that I just wanted to kick around... Perhaps it could
be part of a java policy.
One of the irritating things about the Java packaging scheme is that you
get this functional disassociation because of the organizational boundries.
In other words, you have:
net.novare.ExpiringHashta
16 matches
Mail list logo
