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

["Tarjei T. Jensen" <tarjei.jensen@akerkvaerner.com>]

Warren W. Gay wrote:
> But this is the problem isn't it?  Your needs may be simple, but
> others needs are definitely not.

But we are talking about a simple library for simple needs. Simple as
opposed to all singing, all dancing.

> 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).

It is still beyond the scope of the library to expose the user to those sort
of worries.

> 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.

Yes. Does it worry me? No.

> 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.

Quite the opposite. A simple library serves the needs of the vast majority
of the community.

You keep forgetting that we are talking about the simple library. It does
not preclude a more complicated library for people with more complex needs.

Let me repeat myself: We are talking about a simple user level socket
library which allows user to write simple applications.

> 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).

We do NOT want to extend that library. We want deliberately keep it simple.

> 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.

But this is a libarary for those who have SIMPLE needs. It is not for those
who need complete control.

> 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 are trying to turn something which is intended to be simple and easy to
understand into something so complex that there is NO WAY a novice might try
to use it.

> 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".

When we learn about physics, most of us will get by with Newtonian physics.
Only a selected few have any use for quantum mechanics.

We get by with a gross simplification.

> 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.

Which is perfectly sensible. Because we are intentionally designing
something that is simple. Simple to use. Simple to understand.

We want something which have a reasonable chance of being standardized.
Because there is not much to quarrel about. We don't need 5 years of work to
make sure every little detail is in the specification.

That is why I proposed that these libraries should reside in their own
hierarchy. With the top node being "simple".

greetings,