Re: Ada.Networks.Sockets hierarchy for standardization? (sf: ada0y-net-std)

Re: Ada.Networks.Sockets hierarchy for standardization? (sf: ada0y-net-std)

[Warren W. Gay VE3WWG]

Michael Erdmann wrote:
> Warren W. Gay VE3WWG wrote:
>> For discussion: I have thrown together this evening
>> a more formalized view of some "chicken scratching" I did on my
>> train commute home this evening. The diagram is available at my
>> web site (see PDF link further on).
> 
> I like it. But may be the names services should be put under
> Services.
...
> Michael

While it is too soon to judge general interest in this project, based
upon the pulse of other Ada socket articles in this newsgroup, I think
it is time _something_ was _started_ in this vein. Funding would be
nice, but I don't think we can wait for it. The clock is ticking.

Rather than lose precious time on this, since defining standards and
reference implementations can require considerable effort, I have
taken some initiative and registered a request at sourcforge for
an ada0Y-net-std project to be created there. The website indicates
that they need 2 business days to review and to respond to the request.

If all goes well, I hope to have a project started there by next
Wednesday (June 4th). There we can hold discussions, and more easily
post and revise documents, and later code. They also provide NNTP
access, though I don't know how well it works yet. If it works well,
this would give us our own private newsgroup in which to hold
project discussions in. Alternatively, I suppose an email list
is ok, but I prefer a newsgroup approach, if possible.

This is not to say that no input will be solicited from comp.lang.ada.
Au contrare! However, to reach consensus, you pretty much have to
narrow the list of participants, or your discussion will become a
free-for-all. Meetings with many people take longer and usually
accomplish less. I don't believe that there is much time for us
to waste (if Ada0Y means 2005, then there is little time waste).

The way I see things happening, is that a summary will be posted here
in comp.lang.ada periodically. Interested participants can then come
back to the forge's NNTP server and review past discussions and post
their comments and contributions.

I will be looking for volunteers for various things. I can volunteer
my some of my own time on various things and code, but depending upon
when the submission deadline is, I'll probably need other people to
contribute code and documents as well. Can anyone state when our
ARG submission deadline is? Randy?

For this project to be successful, this project must have
someone to run with this once we have a reference implementation and
document (I don't think I'm the best person for that job).
At a minimum, we need the document to submit (the reference implementation
is to simply help us flush out the problems). So I need
someone to work with the ARG: preferably someone more knowledgeable
about that standards process and perhaps does Ada as
their day job (I am just an Ada hobbiest, after all).

By taking this initiative, I am not necessarily presuming that I should
be the "moderator" or "organizer" of this effort. I would gladly hand
it over to someone else, if they will take the reins and lead this
horse to success. I am just assuming that nobody really wants to take
the time to do this, and so I'll contribute what I can to this
process and at least get things going. If no one steps up to the plate,
then I am willing to take this as far as I am able to. I am really
hoping however, that I can get at least one volunteer to eventually
write up the necessary documentation to submit to the ARG, in the
language and preciseness that they need.

There are already some socket bindings out there, in different forms.
I would be interested in hearing if any of these copyright owners
would be willing to allow portions of those packages to be spliced
into a new framework, for inclusion into the reference implementation.
This project aims to provide a GNAT reference implementation, to help work
out problems. I have registered the sourceforge project to use the
LGPL license, but I suspect that this also needs to be further discussed
and revised (a license selection was required to make the application for
a hosted project).  If you can contribute existing code, then please indicate
what your copyright requirements/restrictions are.

In the worst case of failure, we may just end up with another
non-standard sockets library (or even worse I guess, it might
remain unfinished). But I _want_ this to succeed and I think
there is enough interest generally that this _can_ work. It is my
personal opinion that an Ada without standard socket library support
will cause the language to wither and die, for general purpose
computing uses. Networking today is nearly as important as doing
Text_IO.

Your thoughts?  If you are interested in this project, please indicate
what you can contribute, and capacity/when/how-much if applicable.  If you
feel that this is a "bad idea" or the wrong approach, then don't be
afraid to speak your mind. I'd rather find out now, rather than face
failure a year from now (but state concrete reasons, rather than "I
don't like it" etc.)
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Ada.Networks.Sockets hierarchy for standardization?

[Warren W. Gay VE3WWG]

For discussion: I have thrown together this evening
a more formalized view of some "chicken scratching" I did on my
train commute home this evening. The diagram is available at my
web site (see PDF link further on).

While we're on the subject of sockets and URLs, here is a
shameless plug  8-) for my "Linux Socket Programming by Example"
book (sorry folks, its C/C++ based):

http://www.amazon.com/exec/obidos/ASIN/0789722410/qid%3D996033092/104-8302379-1659946

Before jumping right to the diagram, please read the following
first (otherwise you might GOL (Gasp Out Loud)).

IIRC, earlier discussions centered around something rather simple
like Ada.Sockets as providing all/mostly all of the basic needs
of application programmers.  I am going to propose something a
little bit different, but I do believe that this requirement
for simplicity should be accomodated.  But I believe starting
off too simple would be a great mistake, and severely limit
what could otherwise be a successful, and nearly complete
longer term model for Ada.

To address the "simple requirements" class of applications, I
have included in the diagram the package Ada.Networks.Simple,
for lack of a better name at the moment. Maybe "Basic" would
be better. This package can then use renames and other basic
Ada techniques to pull together all of the basic facilities
into one place, that would otherwise have to be pulled from
a number of other packages and child packages (a la cart).

Now it is probably safe to view the diagram:

  http://home.cogeco.ca/~ve3wwg/Ada.Networks_Hierarchy.PDF

Now you're probably wondering why we need all these "flippin
packages"?  Here's my reasons below:

You will need to lump many aspects of networking under one
umbrella. There is much more to sockets than just sockets
however. I mentioned the need for name services in an
earlier thread. For this reason, and others, I think we
will need to have a top level

   Ada.Networks

package to bring the common elements together.

In my book, I spend an entire chapter showing how to form
socket addresses. This is important because it is a somewhat
arcane thing in C, and the many forms of addresses makes
this essential to cover. I also believe that Ada will need
a top level Ada.Networks.Addresses package from which to
derive child packages for IPv4, IPv6, X.25, AX.25, AppleTalk
and other addresses (also to derive from abstract tagged
records etc.) To allow for extension and additions,
I propose that we then add child packages in the form

   Ada.Networks.Addresses.IPv4, IPv6 etc.

Internet addresses are usually known by names these days,
rather than their IP#'s as in the years gone by. Hence the
need for the Ada.Networks.Name_Services top level package.
Then its subdivided by protocol (I show Internet and X.500).

BTW, I am not suggesting that all of these need to be part
of any initial "offering". But I do believe we
need to make room for them ;-)

Of course, there is the all important Ada.Networks.Sockets
top level package. I can envision 3 child packages, where
the most important one is the Berkeley sockets, and the XTI
sockets. Some may want to also add in WinSock, though now
that XP supports Berkeley sockets, there may not be
any real need for this anymore. I don't want it, but
I left a spot for it.

These packages would concern themselves strictly with the creating,
binding, listening, accepting and other socket basic functions.
The Socket_Type would act as a "handle". I don't see I/O
functions being included here, but this is obviously open
to discussion.

Of course, security is important, and I am not so sure that
I have properly planned for that here. I have suggested that
we need a Ada.Networks.Filters which includes a child
package SSL, that can be "pushed" onto an open socket
similar to the way AT&T UNIX streams worked.

The Ada.Networks.Protocols and their child packages
(particularly Internet) provided constants that pertain
to the types of sockets required. These packages would
have constants that select TCP, IP, UDP, ICMP etc. when
creating a socket. Other protocols of course are possible,
and Linux I know supports X.25 and the amateur radio
AX.25 as two other examples.

The package Ada.Networks.Services.Internet is what you
would use to map http to port 80, ftp to port 21, etc.
These are covered by the services database UNIX calls,
and map well known services to port numbers.

I have thrown in Ada.Networks.XDR to provide endian
neutral communications a la RPC in the C world. Perhaps
this can be used again in "push" fashion on a socket.
The placement and organization of this in large part
depends upon a successful implementation. TBD.

Ada.Networks.Streams, as I see it, would take a Socket_Type
and return some Stream_Type that you could
perform various I/O types of operations on. It would also
include a function to re-expose Socket_Type, so that
calls like shutdown(2) can be performed, if you were
only given a Stream_Type in a subprogram, for
example.

 From Ada.Networks.Streams, I think you could branch out
into varous things like XML, SOAP, ftp, http etc, and
perhaps Text_IO belongs here (I am not sure about this
yet though). But I think this can work.

Finally, package Ada.Networks.Simple would then pull
together in one place, the basic elements out of all
of the packages in Red, that are necessary for the most
basic TCP/IP application needs. This is like using
Simon Wright's fine Booch Components, which is a bit
tricky to instantiate. I use my own "wrapper generics"
to do the same thing that Ada.Networks.Simple should
be able to do, ie, to make it possible to instantiate
everyting in one "go". The Ada.Networks.Simple would
be a "wrapper package" for simplicity's sake.

I see the packages in red as being essential to anything
that is close to being complete. The rest would be gravy,
but these are things that I think we should shoot for.

Keep in mind that the C world already has access to all
of these things, without any further effort.  Because of
this, I think we should support what is possible.  Most
of this stuff is just writing careful thick binding
support. Doing the XDR part portability, is tricky, but
the payback is there.

What do you think?
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Ada.Networks.Sockets hierarchy for standardization?

[Tarjei T. Jensen]

"Warren W. Gay wrote:
> For discussion: I have thrown together this evening
> a more formalized view of some "chicken scratching" I did on my
> train commute home this evening. The diagram is available at my
> web site (see PDF link further on).

First impressions is "not so bad".

However I would re-arrange. I would make sockets the top level node and
arrange everything around that (forget about the ada node; this is Ada.

I would change some names. e.g. streams should be protocols, protocols
should be transport (or something like that).

Anyway, I'm worried that the network programming might drown in a ocean of
packages.

greetings,

Re: Ada.Networks.Sockets hierarchy for standardization?

[Simon Wright]

"Tarjei T. Jensen" <tarjei@online.no> writes:

> However I would re-arrange. I would make sockets the top level node
> and arrange everything around that (forget about the ada node; this
> is Ada.

If it's to be related to the standard it should start at Ada (like
Ada.Streams etc).

Someone else as adopted "Ada0Y" as the top level to avoid compiler
complaints about recompiling standard units.

> Anyway, I'm worried that the network programming might drown in a
> ocean of packages.

Better that than munging everything together so the concepts are
entangled. I dare say there's ahappy medium.

Re: Ada.Networks.Sockets hierarchy for standardization?

[Michael Erdmann]

Warren W. Gay VE3WWG wrote:
> For discussion: I have thrown together this evening
> a more formalized view of some "chicken scratching" I did on my
> train commute home this evening. The diagram is available at my
> web site (see PDF link further on).

I like it. But may be the names services should be put under
Services.

Maybe i have missed it, but what is the difference between red
and black boxes?


Michael

Re: Ada.Networks.Sockets hierarchy for standardization?

[Warren W. Gay VE3WWG]

Michael Erdmann wrote:
> Warren W. Gay VE3WWG wrote:
> 
>> For discussion: I have thrown together this evening
>> a more formalized view of some "chicken scratching" I did on my
>> train commute home this evening. The diagram is available at my
>> web site (see PDF link further on).
> 
> I like it. But may be the names services should be put under
> Services.

Hi Michael:

The problem that I see is that there is a fairly major
distinction between DNS (Name_Services) and what
Ada.Network.Services.Internet represents. The later represents
a database of mappings between numeric port numbers (services)
and their names (ie. "http" maps to port 80).

Name_Services is much more than that. It is an entire protocol
built upon the transport(s) (DNS uses UDP and TCP/IP), and in the
case of DNS, it is distributed and fairly complex in operation.

There are also different name services, and
X.500 represents another from the OSI model. So if you move
these, then I think they should either be grouped under
"name services" or put underneath the general set of protocols
built upon. But I personally like to group name
services together, because they represent one major
"category" of network function.

Maybe an improvement might be to move "Ada.Networks.Services" over
to child package Ada.Networks.Protocols.Internet.Services
instead (these would only be Internet specific of course).
Alternatively, it would be tempting to just merge it right
into the package Ada.Networks.Protocols.Internet. The mappings
for ports and the protocol selection constants aren't that
far apart in concept.

Other protocols like X.25, may not even need a
"services" package. Its been years since I used Datapac (X.25),
but IIRC there is no concept of a port. You just use a DNIC
(address) and perhaps select the service once you connect to the
host at the remote end. Perhaps the service selection is
embedded in the DNIC (I forget). OTOH, the amateur radio
protocol AX.25, which is based upon X.25, does support up to
16 ports (I forget now, but one of these 16 may be reserved).

Take a look at the v2 document below:

http://home.cogeco.ca/~ve3wwg/Ada.Networks_Hierarchy_v2.pdf

Here I moved Services (in blue) underneath
Ada.Networks.Protocols.Internet.  I think that perhaps that
child package might be best merged into Internet, but what
do you'all think?

I still think Naming services should remain distinct, and probably
underneath Ada.Networks somewhere, though package names and overall
organizaton are certainly open for more discussion. Is there
a better name for Name_Services? Should this be Directory or
Directory_Services?

> Maybe i have missed it, but what is the difference between red
> and black boxes?
> 
> Michael

The red just indicated what I believe should be a minimum effort
for a "complete" implementation. The blue in the link above, is
just to highlight the change.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Ada.Networks.Sockets hierarchy for standardization? (sf: ada0y-net-std)

[Randy Brukardt]

Warren W. Gay VE3WWG wrote in message <3ED806D3.5030001@cogeco.ca>...
>While it is too soon to judge general interest in this project, based
>upon the pulse of other Ada socket articles in this newsgroup, I think
>it is time _something_ was _started_ in this vein. Funding would be
>nice, but I don't think we can wait for it. The clock is ticking.
>
>Rather than lose precious time on this, since defining standards and
>reference implementations can require considerable effort, I have
>taken some initiative and registered a request at sourcforge for
>an ada0Y-net-std project to be created there. The website indicates
>that they need 2 business days to review and to respond to the request.


Umm, I have to admit that this has been an action item of mine for the
last 10 months or so. (See AI-292, which is currently empty). My plan
was to put together a group to propose something, but the last time this
subject came up here on C.L.A., there wasn't much support for
standardizing Sockets. So I put my efforts into decoupling the
Claw.Sockets implementation from Claw (and from Windows), so we at least
would have a decent library to use, even if not part of the standard.

If your goal is to make something for the standard, keep in mind that
the important part (and by far the most boring) is writing RM language
for the packages. You'll find dozens of people willing to design and
critique packages, but you will find hardly anyone ready to write the
many pages of RM description needed.

Also, if your goal is to get something into the standard, you really
have to start with existing practice. There are at least three sockets
libraries in current use (Claw sockets [Claw-less version], Gnat
sockets, Ada Sockets), and there is no need to design something from
scratch. Moreover, you'll get more support from the ARG if you do so,
even though the final result probably will differ a lot.

>I will be looking for volunteers for various things. I can volunteer
>my some of my own time on various things and code, but depending upon
>when the submission deadline is, I'll probably need other people to
>contribute code and documents as well. Can anyone state when our
>ARG submission deadline is? Randy?


It depends. For independent outside projects, the deadline is in
September. (I don't think that is enough time.) If the project is
"invited", the deadline is at the end of December. The easiest way to do
that is to convince me that your project is my action item. :-) (Since
it's already open and on the agenda, no one can complain about a
last-minute addition.)

             Randy.

Re: Ada.Networks.Sockets hierarchy for standardization?

[Michael Erdmann]

Warren W. Gay VE3WWG wrote:
> Michael Erdmann wrote:
> 
>> Warren W. Gay VE3WWG wrote:
>>
>>> For discussion: I have thrown together this evening
>>> a more formalized view of some "chicken scratching" I did on my
>>> train commute home this evening. The diagram is available at my
>>> web site (see PDF link further on).
>>
>>
>> I like it. But may be the names services should be put under
>> Services.
> 
> 
> Hi Michael:
> 
> The problem that I see is that there is a fairly major
> distinction between DNS (Name_Services) and what
> Ada.Network.Services.Internet represents. The later represents
> a database of mappings between numeric port numbers (services)
> and their names (ie. "http" maps to port 80).
>
It makes sense. But i gues these service identifiers may have
to be a little more generalized,  for example as SAPI.


> Name_Services is much more than that. It is an entire protocol
..................
> 
> Maybe an improvement might be to move "Ada.Networks.Services" over
> to child package Ada.Networks.Protocols.Internet.Services
> instead (these would only be Internet specific of course).
I think this is a better idea, since the semantic of what is
a service verry mutch depends on the doain or protocol stack
you are looking at.

> Alternatively, it would be tempting to just merge it right
> into the package Ada.Networks.Protocols.Internet. The mappings
> for ports and the protocol selection constants aren't that
> far apart in concept.
> 
> Other protocols like X.25, may not even need a
> "services" package. 
I do not understand this. You can run FTAM on top of X.25 which
is a service. I gues it would a a good idea to give the term
Service a clear definition which fits into the OSI Model.

Its been years since I used Datapac (X.25),
> but IIRC there is no concept of a port. You just use a DNIC
> (address) and perhaps select the service once you connect to the
> host at the remote end. Perhaps the service selection is
> embedded in the DNIC (I forget). OTOH, the amateur radio
> protocol AX.25, which is based upon X.25, does support up to
> 16 ports (I forget now, but one of these 16 may be reserved).
> 
This is the reason why i think, the better idea is to place
the service identifiers alsways near to the protocol stack/domain
they are refering to.

Michael

> 

Re: Ada.Networks.Sockets hierarchy for standardization? (sf: ada0y-net-std)

[Warren W. Gay VE3WWG]

Randy Brukardt wrote:
> Warren W. Gay VE3WWG wrote in message <3ED806D3.5030001@cogeco.ca>...
...
>>Rather than lose precious time on this, since defining standards and
>>reference implementations can require considerable effort, I have
>>taken some initiative and registered a request at sourcforge for
>>an ada0Y-net-std project to be created there. The website indicates
>>that they need 2 business days to review and to respond to the request.
 >
> Umm, I have to admit that this has been an action item of mine for the
> last 10 months or so. (See AI-292, which is currently empty). My plan
> was to put together a group to propose something, but the last time this
> subject came up here on C.L.A., there wasn't much support for
> standardizing Sockets. So I put my efforts into decoupling the
> Claw.Sockets implementation from Claw (and from Windows), so we at least
> would have a decent library to use, even if not part of the standard.
...
>>I will be looking for volunteers for various things. I can volunteer
>>my some of my own time on various things and code, but depending upon
>>when the submission deadline is, I'll probably need other people to
>>contribute code and documents as well. Can anyone state when our
>>ARG submission deadline is? Randy?
> 
> It depends. For independent outside projects, the deadline is in
> September. (I don't think that is enough time.) If the project is
> "invited", the deadline is at the end of December. The easiest way to do
> that is to convince me that your project is my action item. :-) (Since
> it's already open and on the agenda, no one can complain about a
> last-minute addition.)
> 
>              Randy.

Thanks Randy.

Based upon the submission deadlines, I think it would be very ambitious
to pull anything together for the fall, let alone December, unless
someone else wants to lead the charge for this. I was under the mistaken
impression that we had a little more time. Thinking about it now, it
only makes sense for them to cut it off there.

The Source Forge project has been created (I just received confirmation).

Is there any interest in producing a networking library that goes
beyond sockets? As Randy has pointed out, there are already 3 versions
of socket bindings available, and a 4th if you include the partially
complete POSIX interface in Florist.

I personally favour a library that includes more than just TCP/IP sockets.
None of the existing libraries support UNIX sockets yet, that I am
aware of (Florist has plans to, but it isn't supported yet).

But if there is no interest at all, then it is probably best to drop
this project (I am already busy with enough anyway).

But if there is _some_ general interest, then we can "chip away at it".
We would then have at least 10 years ;-) to develop a working model
and have it established.

Your comments?
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Ada.Networks.Sockets hierarchy for standardization? (sf: ada0y-net-std)

[Randy Brukardt]

Warren W. Gay VE3WWG wrote in message <3EDB81DB.4040503@cogeco.ca>...
>Based upon the submission deadlines, I think it would be very ambitious
>to pull anything together for the fall, let alone December, unless
>someone else wants to lead the charge for this. I was under the
mistaken
>impression that we had a little more time. Thinking about it now, it
>only makes sense for them to cut it off there.


Yeah, I was thinking it was further off, too. Time to get to work!

>The Source Forge project has been created (I just received
confirmation).
>
>Is there any interest in producing a networking library that goes
>beyond sockets? As Randy has pointed out, there are already 3 versions
>of socket bindings available, and a 4th if you include the partially
>complete POSIX interface in Florist.


Tom has been working on such a thing based on Claw.Sockets (minus Claw),
but we never came up with a snappy name for it. He has FTP and HTTP
client packages (which I've used to save a lot of time on some quicky
utilities) and a bunch of other things as well.

It would be useful to put together a group to work on it (we'd
especially like to see a Linux body for the Sockets packages, because it
would help find and eliminate any lingering Window-isms in the package
specs) or a similar alternative. It may be best to develop a truly
wide-ranging and portable library as a de-facto standard rather than try
to get one ready in a few months.

            Randy.

Provisional Standards was RE: Ada.Networks.Sockets hierarchy for standardization? (sf:ada0y-net-std)

[Robert C. Leif]

We already have a group on building Ada APIs for XML. I believe that I am
the Chair. I believe that we should minimize the contents of the Ada
standard, yet maximize the contents of standardized Ada libraries. The
creation and modification of libraries often is a continuous process. For
instance, none of us knows what the detailed structure of XML will be at the
end of 5 years. However, we can design a system for creating, what I would
call provisional standards, i.e. a binding for which we have a consensus
with the understanding that it may have to be changed in the future.

An additional virtue of the use of provisional standards is that they can be
extensively tested by implementation and use prior to their formally being
incorporated into Ada. 

Parenthetically, I have no strong attachment to the term provisional
standard. If there is a better or more precise term, so be it.

Bob Leif 

-----Original Message-----
From: Randy Brukardt [mailto:randy@rrsoftware.com] 
Sent: Monday, June 02, 2003 5:40 PM
To: comp.lang.ada@ada.eu.org

Warren W. Gay VE3WWG wrote in message <3EDB81DB.4040503@cogeco.ca>...
>Based upon the submission deadlines, I think it would be very ambitious
>to pull anything together for the fall, let alone December, unless
>someone else wants to lead the charge for this. I was under the
mistaken
>impression that we had a little more time. Thinking about it now, it
>only makes sense for them to cut it off there.


Yeah, I was thinking it was further off, too. Time to get to work!

>The Source Forge project has been created (I just received
confirmation).
>
>Is there any interest in producing a networking library that goes
>beyond sockets? As Randy has pointed out, there are already 3 versions
>of socket bindings available, and a 4th if you include the partially
>complete POSIX interface in Florist.


Tom has been working on such a thing based on Claw.Sockets (minus Claw),
but we never came up with a snappy name for it. He has FTP and HTTP
client packages (which I've used to save a lot of time on some quicky
utilities) and a bunch of other things as well.

It would be useful to put together a group to work on it (we'd
especially like to see a Linux body for the Sockets packages, because it
would help find and eliminate any lingering Window-isms in the package
specs) or a similar alternative. It may be best to develop a truly
wide-ranging and portable library as a de-facto standard rather than try
to get one ready in a few months.

            Randy.

Re: Provisional Standards was RE: Ada.Networks.Sockets hierarchy (Provisional Standard?)

[Warren W. Gay VE3WWG]

Marin David Condic wrote:
> I think that when discussing libraries - especially something like XML 
> that might be in quite a state of flux over the years - that we need a 
> mechanism different from the ARM. If a "Provisional Standard" committee 
> were to exist under some auspices that had the cooperation of some 
> reasonably large subset of the interested players, they could quickly 
> react to changes in the real world. XML may win or lose as a standard. 
> It might evolve or be "embraced and extended". New technology may emerge 
> that makes it obsolete. In this fast paced technological world, nobody 
> has a crystal ball that can see better than a year in advance. Waiting 
> for the ARM to react is a guarantee of failure.
> 
> SIGAda is a forum that could serve to develop and maintain a 
> "Provisional Standard" library. (Isn't that where ASIS originated?) Or 
> the vendors could form up a research corporation that might even become 
> self-sustaining if it produced a library that could generate revenue in 
> the form of support, updates, etc. (Such a research corporation might 
> even be able to get more developed by volunteers by promising some kind 
> of royalties for contributions that are accepted.) I think the forum 
> could be found and the work accomplished, but it needs some kind of 
> direction and acceptance by the vendors.
> 
> BTW: I agree about the name. If "Provisional Standard" is not 
> acceptable, go call it "Harold" for all that it matters to me. ;-)
> 
> MDC

OK, now that some initial discussion has occurred, is there any further
interest in proceeding with the generation of a "provisional standard"?

If so, what should it be called, and were would you like to host it?

I am going to as SourceForge to remove the project that was set up
for me, since it is now inappropriately named (ada0y-net-std).

I know there is some casual interest, but is there any real interest
in starting a "formal project"?   Or is there an existing one that
people should be "pointed to"?

Warren.


> Robert C. Leif wrote:
> 
>> We already have a group on building Ada APIs for XML. I believe that I am
>> the Chair. I believe that we should minimize the contents of the Ada
>> standard, yet maximize the contents of standardized Ada libraries. The
>> creation and modification of libraries often is a continuous process. For
>> instance, none of us knows what the detailed structure of XML will be 
>> at the
>> end of 5 years. However, we can design a system for creating, what I 
>> would
>> call provisional standards, i.e. a binding for which we have a consensus
>> with the understanding that it may have to be changed in the future.
>>
>> An additional virtue of the use of provisional standards is that they 
>> can be
>> extensively tested by implementation and use prior to their formally 
>> being
>> incorporated into Ada.
>> Parenthetically, I have no strong attachment to the term provisional
>> standard. If there is a better or more precise term, so be it.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Provisional Standards was RE: Ada.Networks.Sockets hierarchy (Provisional Standard?)

[Marin David Condic]

I would be interested in working on a standard library for Ada (outside 
the ARM, but considered "Conventional" or "Provisional") However I have 
a couple of reasonable restrictions:

1) We would be totally wasting our time unless we could get some kind of 
acceptance from the folks who could put a label on it that says 
"Official" in some manner. There's some committee covering the Ada 
standard that should be contacted. There are a handful of vendors out 
there that have some level of interest in continuing to develop & 
promote their Ada compilers. They should be contacted. If they say 
"Yeah, we'll work with you on requirements, stamp as "Official" whatever 
you produce and see to it that it gets distributed with the 
compilers...." then you've got something worth working on. Anything else 
is going to be a failure. Trying to get approval and acceptance on 
something like this *after* it gets built won't happen. If it will, why 
hasn't it already happened with one or more of the existing libraries?

2) I am willing to do *some* level of work strictly out of the kindness 
of my heart and desire to see Ada benefit, but I don't think that level 
of effort is going to produce anything more than a few toys. If we want 
to build a *serious* and *credible* library for Ada, it isn't going to 
happen unless there is some money involved somewhere along the line. I 
think a scheme could be set up that would make the production of a 
conventional Ada library something that would pay off. I have some ideas 
about how that could work. What I believe is this: If there isn't some 
payment either up front or down the road, nobody is going to devote much 
time to it and all you'll get is some smallish body of mostly 
unsupported stuff. If it can be somehow turned into a product that 
produces some paychecks somewhere along the line, you can then 
continually grow it into something truly useful and spend time 
supporting it so that developers will feel comfortable using it.

I've got some ideas how this could be made to work. Contact me if you'd 
like to talk more about it off line.

MDC

Warren W. Gay VE3WWG wrote:
> 
> I know there is some casual interest, but is there any real interest
> in starting a "formal project"?   Or is there an existing one that
> people should be "pointed to"?
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

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

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

RE: Provisional Standards was RE: Ada.Networks.Sockets hierarchy(Provisional Standard?)

[Robert C. Leif]

At least in the case of XML, we have a mandate to do something. I propose
that we start with a "Birds of a Feather" evening meeting at SIGAda 2003.
Presently, the only questions are do we start a mailing list and establish a
repository? My feeling on the mailing list is, unless our fellow readers of
Comp.Lang.Ada decide that no longer want to see comments on this subject, we
continue to use Comp.Lang.Ada. The repository is a much more complicated
subject, which should be decided upon by those who provide its contents.
Bob Leif

-----Original Message-----
From: Warren W. Gay VE3WWG [mailto:ve3wwg@cogeco.ca] 
Sent: Thursday, June 05, 2003 1:49 PM
To: comp.lang.ada@ada.eu.org

Marin David Condic wrote:
> I think that when discussing libraries - especially something like XML 
> that might be in quite a state of flux over the years - that we need a 
> mechanism different from the ARM. If a "Provisional Standard" committee 
> were to exist under some auspices that had the cooperation of some 
> reasonably large subset of the interested players, they could quickly 
> react to changes in the real world. XML may win or lose as a standard. 
> It might evolve or be "embraced and extended". New technology may emerge 
> that makes it obsolete. In this fast paced technological world, nobody 
> has a crystal ball that can see better than a year in advance. Waiting 
> for the ARM to react is a guarantee of failure.
> 
> SIGAda is a forum that could serve to develop and maintain a 
> "Provisional Standard" library. (Isn't that where ASIS originated?) Or 
> the vendors could form up a research corporation that might even become 
> self-sustaining if it produced a library that could generate revenue in 
> the form of support, updates, etc. (Such a research corporation might 
> even be able to get more developed by volunteers by promising some kind 
> of royalties for contributions that are accepted.) I think the forum 
> could be found and the work accomplished, but it needs some kind of 
> direction and acceptance by the vendors.
> 
> BTW: I agree about the name. If "Provisional Standard" is not 
> acceptable, go call it "Harold" for all that it matters to me. ;-)
> 
> MDC

OK, now that some initial discussion has occurred, is there any further
interest in proceeding with the generation of a "provisional standard"?

If so, what should it be called, and were would you like to host it?

I am going to as SourceForge to remove the project that was set up
for me, since it is now inappropriately named (ada0y-net-std).

I know there is some casual interest, but is there any real interest
in starting a "formal project"?   Or is there an existing one that
people should be "pointed to"?

Warren.


> Robert C. Leif wrote:
> 
>> We already have a group on building Ada APIs for XML. I believe that I am
>> the Chair. I believe that we should minimize the contents of the Ada
>> standard, yet maximize the contents of standardized Ada libraries. The
>> creation and modification of libraries often is a continuous process. For
>> instance, none of us knows what the detailed structure of XML will be 
>> at the
>> end of 5 years. However, we can design a system for creating, what I 
>> would
>> call provisional standards, i.e. a binding for which we have a consensus
>> with the understanding that it may have to be changed in the future.
>>
>> An additional virtue of the use of provisional standards is that they 
>> can be
>> extensively tested by implementation and use prior to their formally 
>> being
>> incorporated into Ada.
>> Parenthetically, I have no strong attachment to the term provisional
>> standard. If there is a better or more precise term, so be it.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Provisional Standards was RE: Ada.Networks.Sockets hierarchy (Provisional Standard?)

[Marin David Condic]

I would be interested in working on a standard library for Ada (outside 
the ARM, but considered "Conventional" or "Provisional") However I have 
a couple of reasonable restrictions:

1) We would be totally wasting our time unless we could get some kind of 
acceptance from the folks who could put a label on it that says 
"Official" in some manner. There's some committee covering the Ada 
standard that should be contacted. There are a handful of vendors out 
there that have some level of interest in continuing to develop & 
promote their Ada compilers. They should be contacted. If they say 
"Yeah, we'll work with you on requirements, stamp as "Official" whatever 
you produce and see to it that it gets distributed with the 
compilers...." then you've got something worth working on. Anything else 
is going to be a failure. Trying to get approval and acceptance on 
something like this *after* it gets built won't happen. If it will, why 
hasn't it already happened with one or more of the existing libraries?

2) I am willing to do *some* level of work strictly out of the kindness 
of my heart and desire to see Ada benefit, but I don't think that level 
of effort is going to produce anything more than a few toys. If we want 
to build a *serious* and *credible* library for Ada, it isn't going to 
happen unless there is some money involved somewhere along the line. I 
think a scheme could be set up that would make the production of a 
conventional Ada library something that would pay off. I have some ideas 
about how that could work. What I believe is this: If there isn't some 
payment either up front or down the road, nobody is going to devote much 
time to it and all you'll get is some smallish body of mostly 
unsupported stuff. If it can be somehow turned into a product that 
produces some paychecks somewhere along the line, you can then 
continually grow it into something truly useful and spend time 
supporting it so that developers will feel comfortable using it.

I've got some ideas how this could be made to work. Contact me if you'd 
like to talk more about it off line.

MDC

Warren W. Gay VE3WWG wrote:

I know there is some casual interest, but is there any real interest
in starting a "formal project"?   Or is there an existing one that
people should be "pointed to"?



-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

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

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: Provisional Standards was RE: Ada.Networks.Sockets hierarchy (Provisional Standard?)

[Marin David Condic]

I would be interested in working on a standard library for Ada (outside 
the ARM, but considered "Conventional" or "Provisional") However I have 
a couple of reasonable restrictions:

1) We would be totally wasting our time unless we could get some kind of 
acceptance from the folks who could put a label on it that says 
"Official" in some manner. There's some committee covering the Ada 
standard that should be contacted. There are a handful of vendors out 
there that have some level of interest in continuing to develop & 
promote their Ada compilers. They should be contacted. If they say 
"Yeah, we'll work with you on requirements, stamp as "Official" whatever 
you produce and see to it that it gets distributed with the 
compilers...." then you've got something worth working on. Anything else 
is going to be a failure. Trying to get approval and acceptance on 
something like this *after* it gets built won't happen. If it will, why 
hasn't it already happened with one or more of the existing libraries?

2) I am willing to do *some* level of work strictly out of the kindness 
of my heart and desire to see Ada benefit, but I don't think that level 
of effort is going to produce anything more than a few toys. If we want 
to build a *serious* and *credible* library for Ada, it isn't going to 
happen unless there is some money involved somewhere along the line. I 
think a scheme could be set up that would make the production of a 
conventional Ada library something that would pay off. I have some ideas 
about how that could work. What I believe is this: If there isn't some 
payment either up front or down the road, nobody is going to devote much 
time to it and all you'll get is some smallish body of mostly 
unsupported stuff. If it can be somehow turned into a product that 
produces some paychecks somewhere along the line, you can then 
continually grow it into something truly useful and spend time 
supporting it so that developers will feel comfortable using it.

I've got some ideas how this could be made to work. Contact me if you'd 
like to talk more about it off line.

MDC

Warren W. Gay VE3WWG wrote:

I know there is some casual interest, but is there any real interest
in starting a "formal project"?   Or is there an existing one that
people should be "pointed to"?



-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

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

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: Provisional Standards was RE: Ada.Networks.Sockets hierarchy (Provisional Standard?)

[Warren W. Gay VE3WWG]

Marin David Condic wrote:
> I would be interested in working on a standard library for Ada (outside 
> the ARM, but considered "Conventional" or "Provisional") 

Nobody seems to be objecting to this approach. I like the "Provisional"
idea myself.

> However I have 
> a couple of reasonable restrictions:
> 
> 1) We would be totally wasting our time unless we could get some kind of 
> acceptance from the folks who could put a label on it that says 
> "Official" in some manner. There's some committee covering the Ada 
> standard that should be contacted. There are a handful of vendors out 
> there that have some level of interest in continuing to develop & 
> promote their Ada compilers. They should be contacted. If they say 
> "Yeah, we'll work with you on requirements, stamp as "Official" whatever 
> you produce and see to it that it gets distributed with the 
> compilers...." then you've got something worth working on. 

Agreed that the end result is to gain general acceptance, and this
of course includes the vendors.  Do we need this acceptance a priori?

I personally don't think so, and I think it would be difficult to do
so until there is something to present. We need more than an egg,
and something short of a chicken to get there ;-)

> Anything else 
> is going to be a failure. Trying to get approval and acceptance on 
> something like this *after* it gets built won't happen. 

This statement (by itself) is just negative thinking. What are the
real reasons this "won't happen"?  I think this project is like so
many others -- we have to prove it and to sell it.  Some input is
required before we get to that point.  I.e. we collectively
need to assume some risk to make this happen and start something.

> If it will, why 
> hasn't it already happened with one or more of the existing libraries?

There are many reasons and a few of these might include:

- people have been focused on language issues (look at all the
   proposed changes to Ada0Y _language_).

- people have been focused on other existing library shortcomings

- people have been focused on getting their own job done (we have
   at least 4 socket implementations that get the job done in some
   environment, but none are complete or are not completely general.)

Largely, I belive it has been one of getting it organized, expending
the resources on it, and seeing it through to the end.

Take writing a book for an example. It is a monumental task if you
look at everything that goes into it. But with many hands, the task
gets lighter, even though it is still a major effort. It requires
determination and persistence to see it through to the end. It
often requires being able to take constructive criticism and
having a thick skin at the same time. But many authors manage
to do it anyway.

I think if we _really_ want to have a standardized result, then
_we_ can do it. But we'll need to be determined (as a group). "How
badly do we want it?" is basically the question up for discussion
at the moment. If we only "sort of" want it, then this does not
bode well for the project.

> 2) I am willing to do *some* level of work strictly out of the kindness 
> of my heart and desire to see Ada benefit, 

That's great, and I think there are a number of others that will
do the same. In fact, if the project gets enough momentum, I am
sure that even more will become involved at some level or another.

> but I don't think that level 
> of effort is going to produce anything more than a few toys. 

Why? Linux was a toy in the beginning. If it stays as a toy, then
this indicates that the interest in it has languished for some
reason or another. Not necessarily because that the idea itself
was flawed.

> If we want 
> to build a *serious* and *credible* library for Ada, it isn't going to 
> happen unless there is some money involved somewhere along the line. 

Money always helps, no question about it. But a vast amount of
software has been contributed without this requirement. If we want
a sourced-based UNIX, then things like FreeBSD and Linux are the
result. If we _want_ a Ada network library, we _can_ do it without
$upport, if we want to.  I am not saying that we should turn away
support, however.

> I 
> think a scheme could be set up that would make the production of a 
> conventional Ada library something that would pay off. 

I think there is a number of interested parties. Wouldn't it be
nice if networking were as standardized as Ada.Text_IO? Then your
code for Windows, Linux, FreeBSD and whatever would be just one
compile away. Your OpenSourced projects can count on a certain
implementation of sockets being readily available. I don't need
to sell you on this.

> I have some ideas 
> about how that could work. What I believe is this: If there isn't some 
> payment either up front or down the road, nobody is going to devote much 
> time to it and all you'll get is some smallish body of mostly 
> unsupported stuff.

declare
    R1, R2 : Boolean;
begin
    R1 := Small /= Doomed;   -- True
    R2 := Money /= Success;  -- True
end;

> If it can be somehow turned into a product that 
> produces some paychecks somewhere along the line, you can then 
> continually grow it into something truly useful and spend time 
> supporting it so that developers will feel comfortable using it.

I think everyone has a vested interest in standardizing the way Ada
programs interact with the network. If for no other reason than the
saving of time, effort and aggrivation. I think that alone can get
us where we want to go with this. It is certainly the one reason I
am interested in this.

> I've got some ideas how this could be made to work. Contact me if you'd 
> like to talk more about it off line.
> 
> MDC

Perhaps yourself and Bob Leif and I should discuss some ideas offline.
I have also received a couple of other quiet notices of interest by
email. Let's keep an open mind about how we get there, and try to
determine the next steps.  Test, debug and reiterate until we
succeed. ;-)

Any preferences on a mailing list? Perhaps we should start one,
to see where this is going.

Warren.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Provisional Standards was RE: Ada.Networks.Sockets hierarchy (Provisional Standard?)

[Warren W. Gay VE3WWG]

Marin David Condic wrote:
 > I would be interested in working on a standard library for Ada (outside
 > the ARM, but considered "Conventional" or "Provisional")

Nobody seems to be objecting to this approach. I like the "Provisional"
idea myself.

 > However I have
 > a couple of reasonable restrictions:
 >
 > 1) We would be totally wasting our time unless we could get some kind of
 > acceptance from the folks who could put a label on it that says
 > "Official" in some manner. There's some committee covering the Ada
 > standard that should be contacted. There are a handful of vendors out
 > there that have some level of interest in continuing to develop &
 > promote their Ada compilers. They should be contacted. If they say
 > "Yeah, we'll work with you on requirements, stamp as "Official" whatever
 > you produce and see to it that it gets distributed with the
 > compilers...." then you've got something worth working on.

Agreed that the end result is to gain general acceptance, and this
of course includes the vendors.  Do we need this acceptance a priori?

I personally don't think so, and I think it would be difficult to do
so until there is something to present. We need more than an egg,
and something short of a chicken to get there ;-)

 > Anything else
 > is going to be a failure. Trying to get approval and acceptance on
 > something like this *after* it gets built won't happen.

This statement (by itself) is just negative thinking. What are the
real reasons this "won't happen"?  I think this project is like so
many others -- we have to prove it and to sell it.  Some input is
required before we get to that point.  I.e. we collectively
need to assume some risk to make this happen and start something.

 > If it will, why
 > hasn't it already happened with one or more of the existing libraries?

There are many reasons and a few of these might include:

- people have been focused on language issues (look at all the
   proposed changes to Ada0Y _language_).

- people have been focused on other existing library shortcomings

- people have been focused on getting their own job done (we have
   at least 4 socket implementations that get the job done in some
   environment, but none are complete or are not completely general.)

Largely, I belive it has been one of getting it organized, expending
the resources on it, and seeing it through to the end.

Take writing a book for an example. It is a monumental task if you
look at everything that goes into it. But with many hands, the task
gets lighter, even though it is still a major effort. It requires
determination and persistence to see it through to the end. It
often requires being able to take constructive criticism and
having a thick skin at the same time. But many authors manage
to do it anyway.

I think if we _really_ want to have a standardized result, then
_we_ can do it. But we'll need to be determined (as a group). "How
badly do we want it?" is basically the question up for discussion
at the moment. If we only "sort of" want it, then this does not
bode well for the project.

 > 2) I am willing to do *some* level of work strictly out of the kindness
 > of my heart and desire to see Ada benefit,

That's great, and I think there are a number of others that will
do the same. In fact, if the project gets enough momentum, I am
sure that even more will become involved at some level or another.

 > but I don't think that level
 > of effort is going to produce anything more than a few toys.

Why? Linux was a toy in the beginning. If it stays as a toy, then
this indicates that the interest in it has languished for some
reason or another. Not necessarily because that the idea itself
was flawed.

 > If we want
 > to build a *serious* and *credible* library for Ada, it isn't going to
 > happen unless there is some money involved somewhere along the line.

Money always helps, no question about it. But a vast amount of
software has been contributed without this requirement. If we want
a sourced-based UNIX, then things like FreeBSD and Linux are the
result. If we _want_ a Ada network library, we _can_ do it without
$upport, if we want to.  I am not saying that we should turn away
support, however.

 > I
 > think a scheme could be set up that would make the production of a
 > conventional Ada library something that would pay off.

I think there is a number of interested parties. Wouldn't it be
nice if networking were as standardized as Ada.Text_IO? Then your
code for Windows, Linux, FreeBSD and whatever would be just one
compile away. Your OpenSourced projects can count on a certain
implementation of sockets being readily available. I don't need
to sell you on this.

 > I have some ideas
 > about how that could work. What I believe is this: If there isn't some
 > payment either up front or down the road, nobody is going to devote much
 > time to it and all you'll get is some smallish body of mostly
 > unsupported stuff.

declare
    R1, R2 : Boolean;
begin
    R1 := Small /= Doomed;   -- True
    R2 := Money /= Success;  -- True
end;

 > If it can be somehow turned into a product that
 > produces some paychecks somewhere along the line, you can then
 > continually grow it into something truly useful and spend time
 > supporting it so that developers will feel comfortable using it.

I think everyone has a vested interest in standardizing the way Ada
programs interact with the network. If for no other reason than the
saving of time, effort and aggrivation. I think that alone can get
us where we want to go with this. It is certainly the one reason I
am interested in this.

 > I've got some ideas how this could be made to work. Contact me if you'd
 > like to talk more about it off line.
 >
 > MDC

Perhaps yourself and Bob Leif and I should discuss some ideas offline.
I have also received a couple of other quiet notices of interest by
email. Let's keep an open mind about how we get there, and try to
determine the next steps.  Test, debug and reiterate until we
succeed. ;-)

Any preferences on a mailing list? Perhaps we should start one,
to see where this is going. Marin, perhaps you can send me your
email address.

Warren.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

AIs for Ada extensions

[Robert I. Eachus]

Marin David Condic wrote:

> 1) We would be totally wasting our time unless we could get some kind of 
> acceptance from the folks who could put a label on it that says 
> "Official" in some manner. There's some committee covering the Ada 
> standard that should be contacted. There are a handful of vendors out 
> there that have some level of interest in continuing to develop & 
> promote their Ada compilers. They should be contacted. If they say 
> "Yeah, we'll work with you on requirements, stamp as "Official" whatever 
> you produce and see to it that it gets distributed with the 
> compilers...." then you've got something worth working on. Anything else 
> is going to be a failure. Trying to get approval and acceptance on 
> something like this *after* it gets built won't happen. If it will, why 
> hasn't it already happened with one or more of the existing libraries?

The right thing to do here is to get busy and catch up on the proposed 
new packages in Ada0Y.  They can be found in the AIs at 
http://www.ada-auth.org/ais.html  I made up a list of the extension AI's 
I am aware of--Bob and Randy should let me know if I missed any.  Of 
course, in many cases whether an AI is a "normal" AI fixing something 
that is broken or a suggested extension is hard to characterize.  Also 
some of the AI's listed as "other than packages may end up as extension 
packages and vice-versa.  AI-234 for example may end up being resolved 
by having an explicit package that defines a "true" unsigned integer 
type.  (Or such a type may end up in package System, System.Address 
often is such a type.)

Some things to keep in mind if you want to read these AIs and comment.

1) Not all of these AIs will end up in Ada0Y or whatever you want to 
call it.  AI-323 is a good example of something that won't make it.

2) Read the AIs thoroughly before sending comments to the ARG.  If you 
are not sure whether to post here or to the ARG or the Ada-Comment list, 
post here.  There are several ARG members who read this list regularly. 
  If your post should go to the ARG, we will either suggest you send it, 
or forward it.

3) There will be a meeting of the ARG in just over a week.  Fifteen 
extension AIs are on the preliminary agenda.  So some of these AIs will 
change drastically in a couple of weeks.

4) If you do have constructive comments, be very specific.  The more 
detail in your comments, the more they will be listened to.  I think 
there should be a package for ZZZ is not useful.  I think this package 
(see listing below with explantion) should be made part of the standard, 
is more likely to be listened to--and result in lots of other comments.

5) If you want to submit a new package proposal, go ahead.  But have a 
package you use for a rough proposal at least.  "Wouldn't it be nice to 
have..." doesn't belong in the standard.  (If you do have a package that 
your group and several other groups uses, those are good candidates for 
inclusion.)

If you have thin skin or a big ego think carefully before sticking your 
head up.  People don't get attacked at ARG meetings or on the ARG list, 
but ideas get sliced into shreds--often by the original author.  (Think 
of submitting ideas to the ARG as akin to throwing a chunk of meat to a 
well-trained sled dog team.  The dogs may be nice to each other, but the 
meat is going to get torn to shreds and thrown around a lot.) 
Eventually, of course, all of the potential issues have been dealt with, 
and the final proposal may look nothing like the original.  At that 
point the ARG will move on to the next AI.

This is necessary.  You don't want half-baked or changes that were not 
thoroughly examined added to the language.  But it also means that many 
people are best off submitting ideas to the ARG through filters (like 
this newsgroup).  If half a dozen people agree on a particular package 
specification, it might not get torn up too badly by the ARG.  But more 
important, if you are not the only author, you won't take the criticism 
so personally.

So if you want to participate read the e-mail comments on some of these 
AIs. You may then want to arrange to be invited to an ARG meeting.  If 
you survive the meeting, you may even want to join.  Feeling mentally 
wrung out at the end of a meeting is nothing to worry about.  It means 
you were actually following the discussions.  Some of these AIs take 
more than a day to fully understand, and the ARG often deals with more 
than a dozen per day.  Of course, some AIs go through several meetings 
before they are finished.  Some issues are best dealt with in a meeting, 
others are better handled by e-mail.  So a typical resolution is for the 
ARG to accept a set of revisions "in principle," delegate revising the 
AI to someone.  This will be discussed by e-mail and then either an 
e-mail vote is taken, or it goes on the agenda for.the next meeting (again).

Proposed new packages:

AI-248 Directory Operations
AI-282 Ada unit information symbols
AI-292 Sockets Operations (Has a general discussion about standarizing
                            new packages.)
AI-296 Vector and matrix operations
AI-297 Timing Events
AI-301 Missing operations in Ada.Strings.Unbounded
AI-302 Data structure components for Ada
AI-307 Execution-Time Clocks
AI-324 Physical Units Checking

Language Extenstions for Ada0Y other than packages:

AI-217 Handling Mutually Dependent Type Definitions that Cross Packages
           (See also AI-10217, AI-20217, AI-30217, AI-40217 and AI 50217)
AI-218 Accidental overloading when overriding
            (See also AI-10218)
AI-222 Feature control
AI-224 pragma Unsuppress
AI-230 Generalized use of anonymous access types
AI-231 Access-to-constant parameters and null-excluding subtypes
AI-234 Unsigned integer types
AI-249 Ravenscar profile for high-integrity systems
AI-250 Protected Types, Extensible, Tagged, Abstract
AI-251 Abstract Interfaces to provide Multiple Inheritance
AI-252 Object.Operation Notation
AI-254 Downward closures for access to subprogram types
AI-257 Restrictions for implementation-defined entities
AI-260 How to control the tag representation in a stream
AI-261 Extending enumeration types
AI-262 Access to private units in the private part
AI-264 Exceptions as Types
AI-265 Partition Elaboration Policy for High-Integrity Systems
AI-266 Task Termination procedure (See also AI-10266)
AI-267 Fast float-to-integer conversions
AI-270 Stream item size control
AI-274 Requiring complete record representation clauses
AI-281 Representation of enumeration type image attribute
AI-284 Nonreserved keywords
AI-285 Support for 16-bit and 32-bit characters
AI-286 Assert pragma
AI-287 Limited Aggregates Allowed
AI-288 Pre/Postconditions and Invariants
AI-290 Declaring functions Pure
AI-294 Built-in hash function
AI-298 Non-Preemptive Dispatching
AI-299 Defaults for generic formal parameters
AI-300 The standard storage pool
AI-305 Data structure components for Ada
AI-310 Ignore abstract nondispatching subprograms during overloading
AI-314 Standardize Discard_Names
AI-315 Full support for IEEE 754
AI-317 Partial Parameter Lists for Formal Packages
AI-318 Object_Size attribute
AI-322 User-defined operator symbols
AI-323 Allow in out parameters for functions (Status No Action, and that
                                           is highly unlikely to change.)
AI-325 Anonymous access types as function result types (depends on
                                           AI-230)
AI-326 Tagged incomplete types
AI-327 Dynamic Ceiling Priorities

Re: Provisional Standards was RE: Ada.Networks.Sockets hierarchy (Provisional Standard?)

[Marin David Condic]

Warren W. Gay VE3WWG wrote:
> 
> Agreed that the end result is to gain general acceptance, and this
> of course includes the vendors.  Do we need this acceptance a priori?
> 
I don't think you need their a priori acceptance of anything produced, 
but you need some acceptance of the notion that some kind of committee 
or organization is going to be out there producing something that they 
are expected to accept or endorse in some manner. Otherwise, they are 
likely to simply wait to see if there is some market demand that they 
bundle this into their compilers in some way. Then you're back to 
exactly where we are at with things like the Booch components or a dozen 
other decent container libraries. Everybody wanting a "standard" 
container library and no concensus as to which of a dozen available ones 
it should be. The vendors have to get out front and lead here.



> I personally don't think so, and I think it would be difficult to do
> so until there is something to present. We need more than an egg,
> and something short of a chicken to get there ;-)
> 
If you had the vendors and/or the ARG and/or other interested players 
willing to say "Look, we've got a library over here that might make a 
good start and we''re willing to expand on that in some way..." then 
maybe you can make that work. I'm not suggesting at this point that they 
have to sign up to either a) accept without review anything produced or 
b) shell out several million to build it. I'm suggesting that there be 
some kind of informal understanding that they at least accept the idea 
of having some group assemble something like a provisional standard 
library that they would adopt and ship with their compilers. (Or at 
least point to and call it "Ada") Get a gentleman's agreement that this 
is a concept they *might* be willing to sign up for should an acceptable 
product be built and then maybe you can get somewhere.


> 
> This statement (by itself) is just negative thinking. What are the

I'm only negative about an approach that doesn't include the Keepers Of 
The Ada Standard in on the deal. If they are a priori against it, it 
fails. If they are indiferent to it, it fails. The only possibility of 
success is if the library becomes such a universally accepted thing 
without them that they are forced to deal with it. If that was likely, 
why hasn't it happened with one of the already existing container libraries?



> 
> That's great, and I think there are a number of others that will
> do the same. In fact, if the project gets enough momentum, I am
> sure that even more will become involved at some level or another.
> 
Such volunteer efforts have been started in the past. They tend to 
fizzle. I'm not saying it *can't* work - just that it hasn't. Perhaps 
there is a better approach than a purely voluntary, labor of love, 
effort? I think so. We could discuss it off line if you like & maybe 
formulate some ideas together.



> 
> Why? Linux was a toy in the beginning. If it stays as a toy, then
> this indicates that the interest in it has languished for some
> reason or another. Not necessarily because that the idea itself
> was flawed.
> 
For every "Linux" you can point to, I can point to probably several 
thousand fizzled efforts that have never got beyond being amusing toys. 
You might get a nice, solid container library out of it, but that is a 
relatively smallish sort of "toy". A *real* library ought to encompass a 
rather large range of topics (I have ideas on that as well) and it 
quickly becomes something bigger than what could be built and maintained 
by a bunch of part-time volunteers. Or at least unlikely to be built by 
volunteers and you'd get a hodgepodge of cobbled-together pieces lacking 
any consistent "theme" and you'd have uncertain maintenance & support. 
Realistically, I think this needs to be done (or at least picked up by) 
some organized, funded body - and there are ways to do that without 
spending a fortune.


> 
> Money always helps, no question about it. But a vast amount of
> software has been contributed without this requirement. If we want
> a sourced-based UNIX, then things like FreeBSD and Linux are the
> result. If we _want_ a Ada network library, we _can_ do it without
> $upport, if we want to.  I am not saying that we should turn away
> support, however.
> 

Why not try to find some support? I think if there is money behind it, 
it increases the probability of success dramatically.



> 
> Perhaps yourself and Bob Leif and I should discuss some ideas offline.
> I have also received a couple of other quiet notices of interest by
> email. Let's keep an open mind about how we get there, and try to
> determine the next steps.  Test, debug and reiterate until we
> succeed. ;-)

Drop me an e-mail. See my garbled address below. Maybe we can formulate 
some ideas off line.

MDC



-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

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

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: AIs for Ada extensions

[Marin David Condic]

It wouldn't hurt to get up to date with what the ARG is discussing in 
the way of libraries. The ARG might even be the proper keeper of a 
"provisional standard" - or at least an interested party in how that 
works out. My only caution is that tying a library too closely to a 
standards body might slow down or otherwise restrict what an Ada library 
might do.

MDC

Robert I. Eachus wrote:
> 
> 
> The right thing to do here is to get busy and catch up on the proposed 
> new packages in Ada0Y.  They can be found in the AIs at 
> http://www.ada-auth.org/ais.html  I made up a list of the extension AI's 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

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

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: AIs for Ada extensions

[Alexander Kopilovitch]

Robert I. Eachus wrote:

>The right thing to do here is to get busy and catch up on the proposed
>new packages in Ada0Y.
>...
>Proposed new packages:
>...
>AI-302 Data structure components for Ada
>...
>Language Extenstions for Ada0Y other than packages:
>...
>AI-251 Abstract Interfaces to provide Multiple Inheritance
>...

It seems to be an unfortunate collision that multiple new packages should be
proposed when Abstract Interfaces still aren't established firmly.
It is highly likely that some packages (for example, Data structures
components) may look significantly better if they can use Abstract Interfaces.
But one can't expect "widely used" prototype interface-based packages for
standartization until Abstract Interfaces went into practice in Ada.
So, perhaps, standartization of packages that can significantly benefit
from Abstract Interfaces should be delayed, and follow the Core standard
after year or two.



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: AIs for Ada extensions

[Robert I. Eachus]

Alexander Kopilovitch wrote:

> It seems to be an unfortunate collision that multiple new packages should be
> proposed when Abstract Interfaces still aren't established firmly.
> It is highly likely that some packages (for example, Data structures
> components) may look significantly better if they can use Abstract Interfaces.
> But one can't expect "widely used" prototype interface-based packages for
> standartization until Abstract Interfaces went into practice in Ada.
> So, perhaps, standartization of packages that can significantly benefit
> from Abstract Interfaces should be delayed, and follow the Core standard
> after year or two.

I personally don't see any conflict.  The interface AI will allow easier 
bindings to C++ and Java.  But in Ada, mix-ins are a better abstraction 
IMHO for containers.  The advantage is that you can easily put objects 
in a container even if the original declarer of the type/class had no 
idea that they would be put in a container.  For example:

with Ada.Containers.AVL_Tree;
generic
   type Member is private;
   with function Index(E: Element) return String;
   Null_Entry: Member;
package Dictionaries is
   type Dictionary is limited private;
   function Lookup (Key: in String) return Member;
   function Add (M: in Member);
   ...
private
   type Dictionary is new Ada.Containers.AVL_Tree(Member,...);
   ...
end Dictionaries;

(No arguments about how to better do this, please.  This is just an 
expository example)

Notice that using mix-in containers, the type Member doesn't have to 
"know" that it could be added to a Dictionary.  The actual dictionary 
entry will in effect be a child of Member and AVL_Trees.Tree.  But 
Member doesn't even have to be a tagged type...

Re: AIs for Ada extensions

[Alexander Kopilovitch]

Robert I. Eachus wrote:

> > It seems to be an unfortunate collision that multiple new packages should be
> > proposed when Abstract Interfaces still aren't established firmly.
> > It is highly likely that some packages (for example, Data structures
> > components) may look significantly better if they can use Abstract Interfaces.
>
>I personally don't see any conflict.  The interface AI will allow easier 
>bindings to C++ and Java.  But in Ada, mix-ins are a better abstraction 
>IMHO for containers.  The advantage is that you can easily put objects 
>in a container even if the original declarer of the type/class had no 
>idea that they would be put in a container.  For example:
>...

Yes, but what about similar containers, such as various flavors of List?
And it is not an easy task to align properly the above your words with another
your opinion (with which I fully agree), posted here about 3 weeks ago -
I mean the following:

>Date: Thu, 29 May 2003 02:22:22 GMT
>Subject: Re: Problem space and solution space
>
>...  In Ada you tend not to have one sort
>package in your toolbox, or one list type implementation, you have
>several.  Now the programmer solving some problem sees a part of his
>decomposition that can be solved by a list package or a sort package,
>and does a generic instantiation.  The problem is that there is no easy
>way, in Ada, to express a binding to a member of the class of sort
>generics, but to delay the choice of the actual mapping.
>
>This is why one of the features I expect interfaces to add to Ada is a
>better way of organizing collections of sort algorithms and the like.


Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: AIs for Ada extensions

[Robert I. Eachus]

Alexander Kopilovitch wrote:
> Robert I. Eachus wrote:
> 
> 
>>>It seems to be an unfortunate collision that multiple new packages should be
>>>proposed when Abstract Interfaces still aren't established firmly.
>>>It is highly likely that some packages (for example, Data structures
>>>components) may look significantly better if they can use Abstract Interfaces.
>>
>>I personally don't see any conflict.  The interface AI will allow easier 
>>bindings to C++ and Java.  But in Ada, mix-ins are a better abstraction 
>>IMHO for containers.  The advantage is that you can easily put objects 
>>in a container even if the original declarer of the type/class had no 
>>idea that they would be put in a container.  For example:
>>...

> Yes, but what about similar containers, such as various flavors of List?
> And it is not an easy task to align properly the above your words with another
> your opinion (with which I fully agree), posted here about 3 weeks ago -
> I mean the following:

>>...  In Ada you tend not to have one sort
>>package in your toolbox, or one list type implementation, you have
>>several.  Now the programmer solving some problem sees a part of his
>>decomposition that can be solved by a list package or a sort package,
>>and does a generic instantiation.  The problem is that there is no easy
>>way, in Ada, to express a binding to a member of the class of sort
>>generics, but to delay the choice of the actual mapping.
>>
>>This is why one of the features I expect interfaces to add to Ada is a
>>better way of organizing collections of sort algorithms and the like.

Real subtle point.  Interfaces as currently planned will ALLOW multiple 
interface inheritance.  They can also be used as I described in the 
first paragraph to provide multiple instances of a single abstract 
interface.  I expect the multiple (interface) inheritance use to be 
common when interfacing to code written in other OO languages.  The 
usage I described is almost not a programming convention but a way to 
describe the relationship between a number of otherwise unrelated 
abstractions.  They all implement the same interface, so they can be 
passed to generics as instances of that interface, but otherwise there 
is no necessary relation between the abstractions.

Can you use multiple interface inheritance to describe abstractions that 
match more than one interface?  Sure, and it will happen.  For example 
imagine an AVL_Tree package which clearly allows random (indexed) 
access, and also has an ability to do an inorder walk.  It can also 
implement the list interface.  The question is whether it will be 
common.  The problem becomes a programming in the large issue.  It is 
going to be much easier to create a list 'view' of the AVL_Tree package 
and keep it consistant with the list interface, than to maintain a 
package that directly implements multiple interfaces.

This is probably a very good example, so let me follow it through a bit.

    generic
      type Element is private;
    package Lists is
      type List is abstract interface;
      function Head(L: in List) return Element;
      function Is_Empty(L: in List) return Boolean;
      procedure Append(L: in out List; E: in Element);

      type Iterator is private with null;

      function Create(L: in List) return Iterator;
      function Next(I: in Iterator) return Element;
      function At_End(I: in Iterator) return Boolean;

    private
      ...
    end Lists;

I did the iterator this way because it brings up an interesting question 
about interface types.  Obviously an instance of the Lists package also 
creates a new Iterator type, and that type is closely related to type 
List.  But are functions like Next and At_End part of the List 
interface?  I think it is an issue AI-251 needs to address.

Now I want to create a binding between this interface and a tree type. 
The package spec is easy:

    with Lists;
    generic
      with package Trees is new AVL_Trees;
      -- Could make the element type explicit, but no reason to, it is
      -- already specifed by the element type in the AVL_Trees instance.
    package List_View is

      type List is private with null;

      function Head(L: in List) return Element;
      function Is_Empty(L: in List) return Boolean;
      procedure Append(L: in out List; E: in Element);

      type Iterator is private with null;

      function Create(L: in List) return Iterator;
      function Next(I: in Iterator) return Element;
      function At_End(I: in Iterator) return Boolean;

    private
      type List is Trees.AVL_Tree;
      type Iterator is Trees.Inorder_Walk with null;
    end List_View;

Now it gets tough.  Not because it is hard to write, but their is one 
tough decision.  Head is fairly easy to write, start at the root of the 
tree and follow left links until you find one that is null.  The 
contents of that node are what you want to return.  Is_Empty and the 
Iterator operations shouldn't be too hard, since I specified that 
AVL_Trees provides an inorder walk interator.  But what to do about 
Append?  I see three options:

1) Always raise Program_Error.  In other words, this is just a view, and 
not a full list implementation.

2) Raise an error if the new Element does go at the end of the list. 
Err, tree.  This allows the Append operation to be used to insert a 
sorted set of Elements one at a time.

3) Insert the Element at the proper position in the tree, and invalidate 
any existing Iterators, that are past the position the new Element will 
be inserted in, either in the implementation or by fiat.  (In other 
words, document it as an error to insert with an open Iterator.)

Whichever solution you choose, all done.  Notice that we have created a 
binding between one abstraction Lists, and another, AVL_Trees, that 
never explicitly uses the new interface feature to implement multiple 
inheritance.  We could have done it, but some of the List operations 
only loosely make sense for an AVL_Tree viewed as a tree (the Head 
operation) while others will be hidden by the interface entirely.  It 
may be that some of the operations for the List view may perfectly match 
the available operations for the AVL_Tree (Is_Empty?), but many will 
have different names.  So what?  The "overhead" of making the list view 
explicit makes maintenance much easier.

Re: AIs for Ada extensions

[tmoran]

If Interfaces are like the Interfaces in MS Windows dll's, the question
arises: how often do different dll's reuse non-root interfaces?

Re: AIs for Ada extensions

[Alexander Kopilovitch]

Robert I. Eachus wrote:

>...
>Notice that we have created a 
>binding between one abstraction Lists, and another, AVL_Trees, that 
>never explicitly uses the new interface feature to implement multiple 
>inheritance.
>...
>The "overhead" of making the list view 
>explicit makes maintenance much easier.

Yes, all that is fine. But I was much more concerned with basic use of
abstract interfaces (such as in your AVL_Trees example) for containers
than with multiple inheritance. Anyway, now after reading (and rereading -:)
your posting, I think that I got what I wanted: there is a chance that ARG
will pay some attention to the interactions between AI-251 and AI-302,
and will not consider them as completely independent from each other.



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia