Re: Ada package registry?

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> 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.