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 23:05:42 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.icl.net!newsfeed.fjserv.net!news.tele.dk!news.tele.dk!small.news.tele.dk!newsfeed1.e.nsc.no!nsc.no!nextra.com!news2.e.nsc.no.POSTED!53ab2750!not-for-mail From: "Tarjei T. Jensen" Newsgroups: comp.lang.ada 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> <3ED79241.2060908@cogeco.ca> Subject: Re: Ideas for Ada 200X (Ada.Sockets) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: NNTP-Posting-Host: 130.67.226.245 X-Complaints-To: news-abuse@telenor.net NNTP-Posting-Date: Sat, 31 May 2003 08:05:42 MEST X-Trace: news2.ulv.nextra.no 1054361142 130.67.226.245 Date: Sat, 31 May 2003 08:05:21 +0200 Xref: archiver1.google.com comp.lang.ada:38175 Date: 2003-05-31T08:05:21+02:00 List-Id: Warren W. Gay wrote: > 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. I don't want to extend it. I or sombody else may want to make its interface a subset of a more complete socket library. Or possibly make the simple socket library an interface to a more complete library. > BTW, you _will_ want Naming services support. Without them, you'll > not connect to anything, except explicity by IP number. ;-) There is no problem using DNS under the hood in such a library, but there is no need to give the job of handling DNS resolution to the user.(S)he don't want to know. > 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. You will create confusion by adding things the user does not need. A simple library is most likely to be used to echanging textual messages. Once the user starts doing binary stuff (s)he will know more or simply work around the problem. By starting to add features you shoot down in glorious techicolour flames the concept of a simple library that does one thing well. You obliterate the ability for an ordinary user to understand and use the library. You drown userful information in useless gobbledegoook. The road to hell is paved with good intentions and creeping featurism. Resist!!!! Keep it simple! greetings,