Version 1.3 of ais/ai-00292.txt

Unformatted version of ais/ai-00292.txt version 1.3
Other versions for file ais/ai-00292.txt

!standard A.15 (00)          02-04-23 AI95-00292/00
!class amendment 02-04-23
!status received 02-04-23
!priority Medium
!difficulty Medium
!subject Sockets operations
!summary
!problem
!proposal
!wording
!example
!discussion
!ACATS Test
ACATS test(s) need to be created.
!appendix

From: Robert Dewar
Sent: Wednesday, April 17, 2002  8:52 PM

<<I had been planning to propose a Sockets package for Ada, but the experience
with Ada.Directories suggests that this needs to be accomplished some other
way.>>

There are two ways of creating annexes.

One have a small group cobble together something reasonably useful. Then
the language committee holds their noses, and wields the rubber stamp.

Two: vet such annexes with the same care that went in to the main language.
This will indeed take huge amounts of time, this is very difficult stuff
to get precisely semantically right.

****************************************************************

From: Randy Brukardt
Sent: Wednesday, April 17, 2002  9:13 PM

Absolutely right. And the first approach probably is most appropriate for
specialized things such as sockets and containers.

After all, that is essentially how the Ada.Strings facilities were handled.
Someone went off and designed something, the DRs made a few comments (a
couple which were pretty major), the designers updated it, and we adopted
it. There wasn't a line-by-line walk through it. After all, "good enough"
(as opposed to "perfect") is probably sufficient -- it certainly is for
Java.

****************************************************************

From: Bernard Maudry
Sent: Thursday, April 18, 2002  11:54 AM

> I had been planning to propose a Sockets package for Ada, but the
> experience with Ada.Directories suggests that this needs to be
> accomplished some other way.

A Sockets package is now something too late or too low level, as most
developers would prefer 'real' communication packages like the distributed
annex or CORBA, which are already standardized.

It seems to me that it would preferable to focus the effort on what developers
would like to use now, in the future, or both, something like
- a XML interface,
- sorting packages,
- a regular expression package,
- an arbitrary precision integer calculation package,
- an environment variables package,
- and other useful utilities which will avoid to reinvent the wheel every day.

****************************************************************

From: Robert Dewar
Sent: Friday, April 19, 2002  6:25 AM

That's a false impression. We have had steady and wide spread requests for
a sockets package, now satisfied by GNAT.Sockets, which is a widely used
package.

****************************************************************

From: Ted Baker
Sent: Friday, April 19, 2002  6:54 AM

Robert is right about the need for an easy-to-use standard sockets
package.  The distributed annex and CORBA are way to specialized and
heavy-weight to server all needs.  To use them you have to buy in to
using them on both client and server sides, in particular.  Many real
programs are constrained to interact with existing programs that use
existing protocols and communicate via sockets.

Before GNAT.Sockets existed, I was getting regular requests for copies
of both the Florist POSIX socket interface packages (too low-level and
complicated for some users, though), and for the lightweight "gnatsocks"
package I had written for the use of the students in one of my courses.

There is as much need for a simple TCP/IP socket package as there
is need for Ada.Text_IO.

****************************************************************

From: Robert Dewar
Sent: Friday, April 19, 2002  7:47 AM

> There is as much need for a simple TCP/IP socket package as there
> is need for Ada.Text_IO.

This is a good analogy. After all people will sometimes argue that languages
do not need file manipulation facilities because people will use databases
instead. That is true in some circumstances, but we do not take this
argument as applying across the board.

****************************************************************

From: Pascal Leroy
Sent: Monday, April 22, 2002  8:39 AM

> > A Sockets package is now something too late or too low level, as most
> > developers would prefer 'real' communication packages like the distributed
> > annex or CORBA, which are already standardized.
>
> That's a false impression. We have had steady and wide spread requests for
> a sockets package, now satisfied by GNAT.Sockets, which is a widely used
> package.

I concur.  We have seen the same demand several times, for doing lightweight
communication.  Not everyone wants the full power/overhead of CORBA, and the
DS annex is not supported by many implementers.

****************************************************************

From: Tucker Taft
Sent: Friday, April 19, 2002  9:34 AM

Any reason we couldn't adopt GNAT.Sockets as the draft for the Ada 200X
standard Sockets package?

****************************************************************

From: Robert Dewar
Sent: Friday, April 19, 2002  9:45 AM

Providing any use was consistent with the GPL (which seems likely) I see
no reason why not.

****************************************************************

From: Michael Erdmann
Sent: Friday, April 19, 2002  11:57 AM

I dont know it since i am using adasockets Mr. Tardieu, but is there any chance
that this might become the basis of an Annex may be called "...network
interfaces ..." of the Ada RM?

****************************************************************

From: Florian Weimer
Sent: Saturday, April 20, 2002  3:48 AM

Tucker Taft writes:

> Any reason we couldn't adopt GNAT.Sockets as the draft for the Ada 200X
> standard Sockets package?

Some identifiers are not Ada-like at all.  A couple of interfaces are
rather strongly tied to IPv4.  Some interfaces are subject to race
conditions (DNS record sets might change between the calls to
Aliases_Length and Aliases functions, for example).  Some error codes
which do occur in practice are not properly represented.  There are
probably some open questions regarding tasking and protected objects.

IMHO, dealing with network addresses, name lookup, and actual actual
networking operations are so different that they should be provided in
separate packages.

****************************************************************

From: Florian Weimer
Sent: Saturday, April 20, 2002  5:46 AM

> Some interfaces are subject to race conditions (DNS record sets
> might change between the calls to Aliases_Length and Aliases
> functions, for example).

This is completely wrong, of course.  Sorry about that.  (I probably
shouldn't write mail in my current condition.)

****************************************************************

From: Robert Dewar
Sent: Monday, April 22, 2002  2:00 PM

<<Some identifiers are not Ada-like at all.  A couple of interfaces are
rather strongly tied to IPv4.  Some interfaces are subject to race
conditions (DNS record sets might change between the calls to
Aliases_Length and Aliases functions, for example).  Some error codes
which do occur in practice are not properly represented.  There are
probably some open questions regarding tasking and protected objects.>>

Well I have no idea what identifiers are in Floriams HO "not Ada-like
at all"

<<IMHO, dealing with network addresses, name lookup, and actual actual
networking operations are so different that they should be provided in
separate packages.>>

Yes, well obviously we disagree.

And here is the start of yet another demonstration of the futility of
trying to discuss the ideal package for things like this. I certainly
am not going to take part in extended discussion of the optimal form
of sockets interfaces.

I would suggest that if Florian thinks he has a better design, he should
just produce it and implement it. Let the marketplace decide. That's a muhc
better use of energy than endless discussions.

Indeed, internally we argued for ages over the ideal sockets package and
nothing happened, and finally someone wrote one and lots of our users have
found it very useful in its current form (and have made only very minor
suggestions, which we have adopted).

****************************************************************

From: Florian Weimer
Sent: Monday, April 22, 2002  2:59 PM

dewar@gnat.com (Robert Dewar) writes:

> <<Some identifiers are not Ada-like at all.  A couple of interfaces are
> rather strongly tied to IPv4.  Some interfaces are subject to race
> conditions (DNS record sets might change between the calls to
> Aliases_Length and Aliases functions, for example).  Some error codes
> which do occur in practice are not properly represented.  There are
> probably some open questions regarding tasking and protected objects.
>>>
>
> Well I have no idea what identifiers are in Floriams HO "not Ada-like
> at all"

"Shutmode_Type", "Inet_Addr_Type", "No_Sock_Addr".  After all,
we have got "System.Address_To_Access_Conversions" and not
System.Addr_To_Access_Conv". ;-)

> I would suggest that if Florian thinks he has a better design, he should
> just produce it and implement it. Let the marketplace decide. That's a muhc
> better use of energy than endless discussions.

I agree (except for the "marketplace" part).

****************************************************************

From: Robert Dewar
Sent: Monday, April 22, 2002  6:30 PM

>except for the "marketplace" part

by marketplace here I simply mean Ada users. I don't regard anyone else
other than users with problems to solve as having legitimate decision
authority in such matters :-)

<<"Shutmode_Type", "Inet_Addr_Type", "No_Sock_Addr".  After all,
we have got "System.Address_To_Access_Conversions" and not
System.Addr_To_Access_Conv". ;-)
>>

But we also have 'Pos 'Max 'Min etc, so Ada is not that allergic to
abbreviations :-)

Anyway, if you are going to use time and energy to argue about individual
identifier names, you will never gte anywhere. Can I suggest that any
further discussion have a more specific subject (the original subject
line was "Enhancements of the predefined language environment?

I for one would like to be able to kill threads on specific disucssions
of specific enhancements by subject
(starting with "discussions of socket facilities")
:-)

****************************************************************



Questions? Ask the ACAA Technical Agent