Re: Feasibility/Requirements/Wishes of xAL (was: Standard Library Interest?)

[Marin David Condic <nobody@noplace.com>]

Robert I. Eachus wrote:
 > 2) Making it possible and desirable for all Ada compiler vendors to
 > distribute the CAL with their compiles.  This doesn't necessarily
 > require a copyleft, but it will require a common licensing policy.
 >
I wouldn't even *start* the project unless one or more vendors agreed up
front that (in principle) they would plan to distribute the library. I
wouldn't waste my time on some effort such as this if it was going to
meet with the same general attitude that has been exhibited so far:
"Prove that you're the dominant implementation and when enough of our
customers ask for it, we'll include it..." If they won't get on board
with the project, then neither will I.

I'd want them on board for a secondary reason: They can provide some of
the "Market Research" needed to decide what should be in the library and
what should be a priority. Otherwise, we'd again be running off to build
something with no clue as to what the end-users really want to see. Ada
has had enough of that already.

 >
 > I seem to have nominated Marin to be the initial focal point for the
 > CAL effort, and volunteered myself to get the registry started.  I'll
 >
I'd be willing to serve as a volunteer in some capacity and to some
extent, but not without some up-front participation by *some* of the
vendors. (At least one, possibly all.) I've tossed the turd into the
punch bowl - lets see if anyone reacts. ;-)

Realistically, there are limits as to what anyone is willing to
volunteer to do. I could see some SIGAda committee doing some work to
establish *how* a CAL would get built & managed and I'd even be willing
to participate in such a committee. But if something like this is going
to succeed and get done in something less than the customary ten years
it takes to get a language revision, its going to need *more* than
volunteers. It will need some people who are being paid to get results
within an acceptable timeframe.

I think if it was an all-volunteer SIGAda committee, we'd be waiting
probably two years or more before the committee could issue a report
that said "Here's how we expect to develop the library and what sort of
standards we've got for something to be acceptable, etc..." Two years
and all we'd have would be some paper (maybe) - no executable code? Am I
wrong? Would a SIGAda committee of volunteers get a structure in place
to develop/maintain a library, standards written up for coding style,
documentation style, etc., configuration and distribution management and
have a first release of an initial product in six months? How long do we
want to wait to see something concrete?

I think that realistically - while a SIGAda committee of volunteers
might have a role to play - someone is going to have to put up *some*
money and set some milestones or we'll be waiting a real long time to
see anything concrete. We don't have that much time.

I could imagine a bunch of ways of paying for it. The vendors could
dedicate some staff hours to a joint venture & collect up the result.
They could kick in a pool of cash that paid some salaries or other
compensation to some TBD group/organization that would develop the whole
thing. They could form up a business to build it and figure out how to
make it self-sustaining. They could see if there is any R&D money out
there from the government to do this. Any other ideas would be helpful,
but I think that realistically, we need to see some kind of funding or
the process will a) take way too long and b) get uncertain results.



 > try to work out a strawman registration form and website over the
 > next week or so.  Incidently notice that I think it would be nice to
 > have a uniform method of looking up child units and even subroutines
 > within a library--but that is not part of this job.  If CAL is to
 > work, it will need to do that.  But for what I am aiming at, linking
 > to the current website, and having a standard format for some basic
 > information is the "baby step" I talked about.  The sort of stuff Bon
 > is talking about above is part of the next step.
 >
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?

MDC
-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m c o n d i c @ a c m . o r g

     "All reformers, however strict their social conscience,
      live in houses just as big as they can pay for."

          --Logan Pearsall Smith
======================================================================