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-06-01 13:55:26 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!cyclone.bc.net!sjc70.webusenet.com!news.webusenet.com!pd2nf1so.cg.shawcable.net!residential.shaw.ca!feed.cgocable.net!read1.cgocable.net.POSTED!53ab2750!not-for-mail Message-ID: <3EDA680D.3050703@cogeco.ca> From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Ideas for Ada 200X (Ada.Sockets, enlightened) 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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 01 Jun 2003 16:54:37 -0400 NNTP-Posting-Host: 24.150.168.167 X-Complaints-To: abuse@cogeco.ca X-Trace: read1.cgocable.net 1054501217 24.150.168.167 (Sun, 01 Jun 2003 17:00:17 EDT) NNTP-Posting-Date: Sun, 01 Jun 2003 17:00:17 EDT Organization: Cogeco Cable Xref: archiver1.google.com comp.lang.ada:38294 Date: 2003-06-01T16:54:37-04:00 List-Id: Tarjei T. Jensen wrote: > 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. But this is the problem isn't it? Your needs may be simple, but others needs are definitely not. > 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. It is easier to provide a "simpler interface" from a more complete (and thus more complicated interface). I sense that you've not been using Ada very long. Ada has very strict rules, including package visibility rules. If you get your package hierarchy wrong, you'll paint yourself into a corner. You'll see ;-) >>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. They might not "want to know", but there often is no choice in that. Yes, for TCP/IP, you can make assumptions about what a string represents and do the necessary lookups on their behalf (IIRC, Java does this). But there are a number of situations where things are much more complicated than that. Here's one: You want to connect to a web server, but you're not getting any response (the web server is down). Yet, if you were to use the name server in a more advanced way, you could find out that there are alternative web servers (all having the same name, but possessing different IP numbers). Doing a lookup today on www.yahoo.com, I saw 9(!) different IP#'s that can be used to reach a web server. An application exploiting that information could bypass the one server that is down, but trying one of the other 8. Your "simplified" application would have to report a failure to connect. So your needs might be simple, but simplified libraries don't help everyone else that are solving more difficult problems. >>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. But there are _many_ users, with _many_ different needs. What you want is something real simple. This serves only a small portion of the overall community. Part of the challenge for standards and library writers is striking a comfortable balance between simplicity (elegance) and general utility (functionality). And it does require careful planning and compromise. But beware: if you compromise too much towards a simple library, you will only be able to address simple needs. Additionally, in Ada, this can be difficult to extend later (more on that later). > 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. This is the kind of problem that people want to solve. They don't want to have to write Ada bindings to "work around the problem". The problem is that the library doesn't exist in standard form. You may only want to exchange text, but many here need to much more than that. With no attempt to offend here, but if you want a simple environment to learn in, then there are other environments like BASIC. For networking, Java has a simple network model, but for more difficult problem spaces, it too has "problems". > By starting to add features you shoot down in glorious techicolour flames > the concept of a simple library that does one thing well. There are many computing problems that are anything but simple. Networking, is one of them. Yes, you can do simple networking, but simple networking only solves simple network problems. If your problems are always simple, then good for you. I am not interested in "adding features". I am interested however, in a complete solution. Microsoft sells features (flying folders and animated paperclips etc.). We in comp.lang.ada are interested in serious solutions to programming problems. Some programming problems are very serious, and have a bearing on the safety of human lives. You're obviously fond of the simplicity argument so let's review Einstein's statement that "things should be simple, but not simpler": You've focused on the phrase "things should be simple". But Einstein was very careful to add "but not simpler". This means that if the solution is too simple, then it does not solve the problem (in the case of physics, this means that the theory does not map to reality). A simple but _complete_ solution is elegant. A simple but incomplete solution is not only ugly, but is by definition "incomplete". The "earth is in the center of the universe" theory was very attractive because of its simplicity. Yet today, you don't think that way, because you have been trained to know that the universe is more complicated than that. To go back to that kind of thinking with what you know, would be regressive. Let's not regress in what we've learned about networking to date. > You obliterate the > ability for an ordinary user to understand and use the library. You drown > userful information in useless gobbledegoook. "Gobbledegook" may be the way you see it now. After your apprenticeship is over, you will see it in a different light. I had very little respect for Calculus before I learned how to handle differentials and perform integrations. Before I was trained in these things, calculus looked like a bunch of "Greek stuff". After I learned what it was about, it became a powerful tool in my hands. You too can eventually reach "enlightenment". ;-) > The road to hell is paved with good intentions and creeping featurism. > Resist!!!! > > Keep it simple! Your "good intentions" or mine? You have good intentions, but they will paint you into a corner if you focus on simplicity only. The solution must also be complete, or at least allow it to be complete someday. With the strict Ada visibility rules of child packages, and the danger of circular package references (which won't compile), you really do have to "plan ahead". Anyone that has written Ada libraries as a set of packages learns this lesson (sometimes we continue to re-learn it ;-) If you only plan for the simple, you'll be stuck there. The only way out will be to tick people off by making wholesale package changes later. NOBODY wants those kinds of changes. What we decide today, we will be stuck with for another 10 years. Probably very much longer than that. I hope that helps to enlighten. ;-) -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg