Re: Why no socket package in the standard ?

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

On 24.05.11 14:53, Dmitry A. Kazakov wrote:
> On Tue, 24 May 2011 12:00:24 +0200, Georg Bauhaus wrote:
> 
>> Opposing a get-that-duct-tape-solution-out嚙碾the-door style for
>> standardization, I'd imagine starting from questions like the
>> following and then weigh POSIX sockets as the possible answer:
>>
>> - What should programs be able to do when communicating data
>>   along some network connection?
> 
> Well, this has nothing to do with sockets.

It hasn't.  (My point.)

> Communication between programs
> is distribution, the annex E.

Yes.  If the endpoints of communication are Ada partitions.
Otherwise ...?

> Sockets are a about communication to the
> hardware, even if the other side is actually a program.

From a programmer perspective, sockets may well be about
how to send a String value to some "Port" on some
"machine" identifiable via DNS.

No hardware in sight from this viewpoint.

Whereas network communication may well be different, as you have
outlined.

>> - Should there be a layered approach?  How much detail?
> 
> This is the above question again. If distribution meant, there is the
> program (application) level only. Then the question is not about the
> levels, but about the architecture of such communication (object vs event
> vs procedural vs data views etc)

Yes.


>> - Is sockets the right approach?  Consider Erlang!
> 
> An approach to what?

A more general approach to sending data around.  That's what socket
programs do very frequently, I think, at least when they stream text,
for example. From the programmer's point of view, they use text based
protocols. Not datagrams or packages or anything.  This defines one use
case of (technically sockets based) data communication.

Why insist on sockets, then?

>> - Is sockets the right approach?  Consider a CAN!
> 
> CAN is not stream- or packet-oriented, not even Ethernet. Even
> Ethernet-based protocols, such as EtherCAT are have nothing to do with
> sockets.

Which is why I had hoped to remind that Ada programs, even when
operating a network, might not profit at all from a standard sockets
package, if they do not use sockets, but do control networked communication.

> Blurring transport and application level issues does not help.

Yes.  But at least we might try to learn, for the purpose of standardization,
what a typical transport level issue is versus what an application level issue
is---not so much about how solutions are built around sockets whenever
these happen to be available.  Standards work seems a good opportunity
to isolate, in abstract terms, what a transport level issue is.   (And what it
might or might not have to do with Ada, or sockets, see below.)

If these issues are central to Ada programming, and future-proof,
there might be funding for isolating a few requirements.  Then start
from these requirements.

Or, if sockets are as important as, say, timers, or windows---if they
are important, then enlighten industry (or govt.) that they have the power
to ask for compiler-independent packages. These would not even
need ISO standardization, just compiler independence, to be used
by industry.

No one else has the power.

Consider libraries like public roads or not-so-public infrastructure
that everyone needs.

Remembering industry's built-in rewards system for anti-co-operation,
its power to influence the software makers towards generally useful
packages is unlikely to be employed, though.  (Packages that could
be used with a different compiler! By a different company!?)


>> I doubt that the best answer to these questions can
>> be summed up by saying, "Mirror Posix sockets!".
> 
> What was the question? (:-))

The original question was, "Why no socket package in the standard?".

Let me rephrase it: "Why no ISO/IEC 14519:2001 package in the standard?"

I believe there was a preliminary answer to the latter question
that might show the first in a new light.