Re: Ideas for Ada 200X (Ada.Sockets)

["Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca>]

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