comp.lang.ada
 help / color / mirror / Atom feed
From: "Robert I. Eachus" <rieachus@comcast.net>
Subject: Re: Feasibility/Requirements/Wishes of xAL (was: Standard Library Interest?)
Date: Sun, 12 Oct 2003 22:54:55 GMT
Date: 2003-10-12T22:54:55+00:00	[thread overview]
Message-ID: <3F89DB96.80708@comcast.net> (raw)
In-Reply-To: 3F897415.6030804@noplace.com

Marin David Condic wrote:

> I'm not sure what the value of some kind of name registration would be.
> Perhaps you can explain it better. It seems to me that you're proposing 
> that, for example, "GtkAda" could register the root name "GtkAda" and 
> nobody else would then use it for a library they intended to build? I'm 
> not clear on what that does for establishing some kind of library. I 
> don't see a bunch of people clamoring to use the name "GtkAda" as the 
> root for their package now, so I'm not understanding what problem we're 
> trying to solve here. Does GtkAda become some "Semi-Official" part of 
> Ada by virtue of registering the name? How does that help?
> 
> It seems that you could have fifty different packages doing essentially 
> what GtkAda does and all of them having some "Official" name and none of 
> them being shipped by the vendors. How is that different than what we 
> have now? AFAIK, we don't seem to have a namespace problem with the 
> assorted libraries out there on the internet, so I'm wondering what we 
> get for this?

First notice that without a group working on CAL or whatever name is 
chosen, this isn't much use at all. The bit about avoiding name 
conflicts might be helpful in a vacuum, but that is about it.

However, if we do have a serious collaborative library building effort 
going on, or several of them, then having the registrar in place and 
working deals with several major problems and has one side benefit.

The major problem is that there are names and areas which are potential 
minefields.  For example, GNADE uses ODBC.  ODBC is a Microsoft 
standard.  It would be really nice to name the package that supplies the 
thin binding to ODBC, something.ODBC, and have Microsoft's permission to 
do so.  This is part of what the registry is there to accomplish, just 
like the process for registering domain names on the Internet.

In addition there are some names which may be highly prized and others 
which should be used for implementations of particular bindings or 
libraries.  I don't care if CAL has a CAL.BLAS which has nothing to do 
with the Basic Linear Algebra System. (Well, I think it would be silly, 
and if I got a vote inside CAL I'd probably vote against it.) But I 
think any "root" library named BLAS would only be given to a (complete, 
working) BLAS implementation.  Similarly I can't see any legitimate 
standards group approving the name GtkAda for anyone except the authors 
of GtkAda.

Now comes the side benefit...  There are certain Microsoft bindings that 
won't get into CAL or any such library without Microsoft's blessing.  To 
the extent that Microsoft wants to control such bindings, they will. 
But if there is a registry in place and well managed, it will be a lot 
easier to get sensible Ada bindings to Microsoft (and other company's) 
interfaces registered and with sensible copyright restrictions.  No, 
that doesn't mean that we can talk Microsoft into going to open source 
licensing for everything.  But it should mean that they will agree to 
have the package spec free for copying without modification, even if 
Microsoft wants you to buy their implementation.  (But I expect that 
Microsoft will be willing to make any necessary Microsoft bindings 
available from their website.  They have in the past.)

I used Microsoft to be specific.  But there are other companies such as 
Oracle, Sun, and even ACT where before we are done we may have to deal 
with trademark and copyright issues.  Do it right from the start, and 
there may even be funding from someone other than the compiler 
companies.  But if we don't start out with the right intentions--to do 
our best to acknowledge and protect copyrights and trademarks without 
making the libraries impossible to use--then we will fail.
-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig




  parent reply	other threads:[~2003-10-12 22:54 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-09 17:33 Feasibility/Requirements/Wishes of xAL (was: Standard Library Interest?) Ching Bon Lam
2003-10-09 18:22 ` Martin Dowie
2003-10-09 18:29 ` Stephane Richard
2003-10-10 16:18   ` Martin Dowie
2003-10-11  7:48 ` Martin Krischik
2003-10-12 11:13   ` Ching Bon Lam
2003-10-11 21:56 ` Ching Bon Lam
2003-10-12  4:18   ` Robert I. Eachus
2003-10-12 15:32     ` Marin David Condic
2003-10-12 16:51       ` Stephane Richard
2003-10-12 23:29         ` Marin David Condic
2003-10-12 22:54       ` Robert I. Eachus [this message]
2003-10-12 23:37         ` Marin David Condic
2003-10-13  1:02           ` Robert I. Eachus
2003-10-13  9:58             ` Stephane Richard
2003-10-13 19:58               ` Robert I. Eachus
2003-10-13 20:57                 ` Stephane Richard
2003-10-13 12:13             ` Marin David Condic
2003-10-12 13:57 ` Freejack
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox