From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,80ae596d36288e8a X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,BIG5 Path: g2news2.google.com!news4.google.com!feeder.news-service.com!news.netcologne.de!ramfeed1.netcologne.de!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Tue, 24 May 2011 16:28:32 +0200 From: Georg Bauhaus User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Why no socket package in the standard ? References: <872169864327910446.796089rmhost.bauhaus-maps.arcor.de@news.arcor.de> <9cb23235-8824-43f4-92aa-d2e8d10e7d8c@ct4g2000vbb.googlegroups.com> <4ddb5bd7$0$302$14726298@news.sunsite.dk> <4ddb81b8$0$7628$9b4e6d93@newsspool1.arcor-online.net> In-Reply-To: Content-Type: text/plain; charset=Big5 Content-Transfer-Encoding: 8bit Message-ID: <4ddbc090$0$6582$9b4e6d93@newsspool3.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 24 May 2011 16:28:32 CEST NNTP-Posting-Host: 11dce352.newsspool3.arcor-online.net X-Trace: DXC==kX=>OQimD4RLigj];iP=8McF=Q^Z^V384Fo<]lROoR18kF:Lh>_cHTX3j= X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:20377 Date: 2011-05-24T16:28:32+02:00 List-Id: 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�Vthe-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.