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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,38fc011071df5a27 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-05-30 10:32:56 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!cyclone.bc.net!news.uunet.ca!nf3.bellglobal.com!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail Message-ID: <3ED79241.2060908@cogeco.ca> From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Ideas for Ada 200X (Ada.Sockets) References: <6a90b886.0305262344.1d558079@posting.google.com> <3ED4A94C.2020501@noplace.com> <3ed4c9a2@news.wineasy.se> <3ED4EB4E.6050108@cogeco.ca> <3ED63B23.5040308@cogeco.ca> <3ed7278b@news.wineasy.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 30 May 2003 13:17:53 -0400 NNTP-Posting-Host: 198.96.223.163 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1054315072 198.96.223.163 (Fri, 30 May 2003 13:17:52 EDT) NNTP-Posting-Date: Fri, 30 May 2003 13:17:52 EDT Organization: Bell Sympatico Xref: archiver1.google.com comp.lang.ada:38127 Date: 2003-05-30T13:17:53-04:00 List-Id: Tarjei T. Jensen wrote: > Warren W. Gay wrote: > >>I am not saying it shouldn't be done, but I think you've overly >>trivialized it. 8-) > > No I haven't. I have made something 99,95 percent of Ada ordinary users > could use. Successfully.The issues you raise complicates matters and creates > confusion. It is the stuff you put in a specialized library. It is NOT > something for the unwashed masses. I have already conceded that the "TCP basics" would be a "Good Thing" (TM). But going from being a "Good Thing" to "the only thing we need" is an entirely different matter. If you only plan for TCP in your socket support, you will have an "unwashed mess of package(s)" which will be ugly or difficult to extend for other important network functionality. Some of which, may not be well understood or anticipated at this time. BTW, you _will_ want Naming services support. Without them, you'll not connect to anything, except explicity by IP number. ;-) > PLEASE read "The Inmates Are Running The Asylum". Less is more! Focus on > something to do well. > >>I think most people would settle for a good TCP >>level API for applications. But this would need to include naming >>services at a minimum, and ideally Ada streams with >>endian neutral I/O to be truly useful. > > That is extras! Oh? How are going to connect to http://adapower.com from your Ada socket program? Are you going to code that it must connect to 216.92.66.46 instead? What if their IP number changes with time as it would with PPP/DHCP? Trust me -- you _will_ want the naming services. 8-P "They is not extra!" Ada streams and endian issues are also important. Write a program that uses a socket between two endian different machines and the endian issue becomes painfully important. This also shows up in the strangest places. My APQ PostgreSQL package lets you use Ada streams to write blobs to the database. Well, guess what. If you have machines of a different endian persuation trying to read back those blobs written by a different endian persuation (with Ada streams), then "they ain't right". Right now, I live with that limitation because there is no elegant way to fix this. Since Ada streams was important for the designers to allow programs to read/write Ada objects to/from files, I think it is consistent to say the same "need" exists with sockets. Mix in sockets, and endian issues also come into play. >>It would also be useful for Ada0X to include some extensions to the >>distributed annex to consider standard ways to authenticate. This is >>perhaps one of the biggest thorn patches for distributed computing in >>hostile environments. I would love to see SSL (perhaps) as a builtin >>selectable option for the channel filter for example. > > I would not mind having that, but it is still extras. I would agree that this is "extra", but there still exists a "need" there. As soon as you write a distributed program that must communicate with a 3rd party, this becomes a difficult issue. Or if the communication path is over the hostile inet. If someone/group were to solve this as a "standard", and that standard stood the test of time (security wise), a great deal of effort would be saved by many by having this accomplished. And then we can all reap the benefits in services that this could make safely available. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg