Re: Why no socket package in the standard ?

["Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr>]

Le Tue, 24 May 2011 16:28:32 +0200, Georg Bauhaus  
<rm.dash-bauhaus@futureapps.de> a écrit:
> From a programmer perspective, sockets may well be about
> how to send a String value to some "Port" on some
> "machine" identifiable via DNS.
Not only, the concern is also about the protocol behavior, that is mainly  
reliable/non-reliable, stream/non-stream. What make the difference between  
stream and non-stream, is the reliability… TCP/IP is looking like a PIPE,  
except for its identity, UDP/IP is not.

> 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.
I do not see what fund your proclamation “Not datagrams or packages or  
anything”. UDP is really used when it does not matter a lot when some data  
is lost on reception or emission (used for example, for some kind of  
continuous real-time stream).

> Why insist on sockets, then?
Good question. May be talking about IPC would be wiser then. After all,  
IPC could be seen as a primitive for RPC, which Ada already talks about.

> 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.
Be pragmatic. Nothing is totally 0 or totally 1. The kind of application  
you are pointing, are the most rare, the one targeted by sockets, are the  
most common of the two.

> 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
Reliability levels (and identity also).

> 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.
I welcome this “isolating a few requirements”, cause as replied elsewhere,  
some part of the BSD sockets would probably not be welcome (raw sockets).

> 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.
May be an option, I agree. Still that as replied elsewhere, you still lack  
an answer to the other option : why would fund the rejection ?

> No one else has the power.
Pragmatism would suggest the community of active developers (proprietary  
or not).

> 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!?)
There is no way to be afraid of such things with sockets. Or do you see  
some ?

> 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?"
There is no way to rephrase it this way. POSIX is not comparable to  
sockets.


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.
“ c++; /* this makes c bigger but returns the old value */ ” [Anonymous]