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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!gegeweb.org!news.ecp.fr!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Ada package registry? Date: Thu, 4 Feb 2016 15:03:51 -0600 Organization: JSA Research & Innovation Message-ID: References: <02241ec4-0f95-4f63-9abc-092f167eb59e@googlegroups.com> <56af17b7$0$301$14726298@news.sunsite.dk> <56b06eb8$0$301$14726298@news.sunsite.dk> <1454483747.2785.135.camel@obry.net> NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1454619832 27841 24.196.82.226 (4 Feb 2016 21:03:52 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 4 Feb 2016 21:03:52 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:29345 Date: 2016-02-04T15:03:51-06:00 List-Id: "Dmitry A. Kazakov" wrote in message news:n8v49a$19uo$1@gioia.aioe.org... > On 03/02/2016 23:11, Randy Brukardt wrote: ... > It is an alternative to OpenSSL. Regardless of the merits of encrypted > network protocols, the problem is indicative to the weakness of Ada > community. There is nothing in OpenSSL or GNUTLS that would prevent them > designed in Ada. Precisely. I'd be more likely to implement the underlying protocol in an Ada package set than I would be to use some third-party library to do the job. I might do something different if I needed a quick and dirty solution, but I surely wouldn't stake my business on such things. ... >> Sockets have been part of Windows since Windows 95, and I think part of >> Unix >> much longer than that. Nothing 3rd-party to use sockets. And of course, >> I'm >> mostly used Claw Sockets (part of Claw), or the generic version thereof >> (NC >> Sockets). We of course have an ecosystem of tools and libraries built on >> top >> of those. (One of the projects I'm working on occassionally in my spare >> time >> is erasing lingering Window-isms in them and testing them on Linux; once >> done I intend to release the entire set of libraries under the BSD >> license.) > > The problem with external socket libraries is handling "esoteric" stuff > like socket select, raw sockets, socketCAN etc. External libraries do not > work well across platforms and are too low-level, e.g. asynchronous > socket I/O is not integrated integrated with Ada tasks. Right, but I'm of the opinion that most users don't need that "esoteric" stuff. I've(*) been concentrating on making sockets as easy to use as possible, which necessarily is going to cost a bit of performance. But as with all things, performance has to be measured -- it's almost never what you expect to be a problem that turns out to be the real bottleneck. Case-in-point: the web server that runs Ada-Auth.org. I was concerned that the sockets library would be too primitive to handle bursts of traffic, that Janus/Ada's cooperative multitasking would be a problem, and that the expensive operations that essentially stop the entire web server would make performance too choppy to be usable. But in actual fact (and even though the server machine is way underpowered for what it is doing), the real problem when the server has been overloaded has been the size of the Internet pipe to the server. It gets clogged long before the server grinds to a halt. So most work on server performance would have been just be wasted. ... > Yes, but that applies to the OS as well. We cannot fix that, but we should > try to get as much stuff as possible in Ada. Which is why Ada community is > important. My fantasy of course included running on top of an all-Ada OS. I eventually concluded that one has to pick their battles, and it made most sense to consider the OS the foundation and build up from there. But in an ideal world, I would run no C at all, and hardly anything that I don't have Ada source for. Sigh - the real world is never ideal. Randy.