Allow software porting from other platforms (read as: Unix programs)

A brand new, clean TCP/IP service would still have to provide some "bsd" wrapper.

I think you are all afraid of the Unix code, despite the fact that the BSD implementations are considered to be the premier implementations of the whole thing, at least by some people.

The BSD API is unpopular with whom? AT&T tried to reinvent the API, and nobody took that up, so what is wrong with it.

Most of the example code in the world uses sockets, all the network programming books.

If we don't have POSIX compatibility at some level it'll make porting TCP/IP applications from any other platform a pain.

Personally I don't like the ANDI approach... but maybe I'm too used to programming with the BSD socket library. I recently implemented multicast support on a set top box over BSDsockets and without any problem whatsoever. There are many issues that depend on TCP itself rather than on implementations and BSD offer just the instruments useful to avoid or limit those issues. Nobody's perfect, but Cisco IOS stack derived from BSD (it's different in many ways, but it's a direct BSD derivative) and this has a lot of sense and implications for me.

... In the document you've indicated I saw several "unique features" and "common problem solutions" that are the same applied on BSD... I think that we should approach this matter without looking beyond the horizon when we have a definitely not so bad solution in front of us.

You can argue that "we don't need those stinking applications" & I'd agree, if there was enough interest to write a web server etc.

A lot of Amiga applications uses the BSD API.

The problem is AFAIK the fact that you cannot wait for AmigaOS signals at the same time you're doing an select(). Say for example you wanted to (all at the same time):

• Wait for event's from the GUI
• Wait for timer events
• Do async file IO
• Do async network IO

That why you have SelectSignal() (or what it's called) in AmiTCP (i.e., select() with a time-out + waiting for signals; which in itself suggests that AmiTCP uses them internally somehow).

I think the Amiga "connectivity" would have been a lot better if they would have gone for a more elegant, "Amiga-ish" solution instead.

Because it uses the 'everything is a file' philosophy of Unix and not the device philosophy of Amiga. It's not the use of sockets that is a problem it is the way you access them.

Part of the "problem" is that the API is linked into the POSIX way of doing things, if you then have a separate POSIX layer for read()/write() calls etc., you get a problem. The only one I can quote from the top of my head is ioctl(). There are workarounds for the problem: winsock uses ioctlsocket() instead, for instance. Having to create another process for blocking calls is also a tad painful at times.

> OK, what is the difference between say, ioctl(), or setsockopt() and an > Amiga-like call such as SetObjectA()?

Not much, really. The real problem comes when trying to be POSIX-compliant, you need an ioctl that can work on files TCP/IP etc. So, you have to avoid using those functions for native support unless you go the whole hog and move ioctl into dos.library somewhere.

A brand new API for network services is something that should look and feel like any other OS component. Dealing with network I/O should't be much different from dealing with exec messages (or anything similar).

I'm just saying that I think everyone should be aware of the danger relying on some Unix-style API could mean. "Why even bother developing a webserver when there's Apache?" "Why waste time writing a 'finger' utility when I can compile some GNU flavor right out of the box?". If I want to run stuff taken from the Unix world, then I run Linux. If I want to run stuff taken from the AmigaOS world, then I run AROS.

• The alternative is nobody writing a web server AND we can't use Apache. It's a tough call, but I think we ought to have POSIX compatibility.

I don't think we should settle for some simple "bsd" API wrapper; it should rather be the other way around; a network service acting as an integrated piece of the OS core, just like any other runtime component (with an optional "POSIX" wrapper).

Functions can be stored within devices. However, as long as the architecture permits it I/O should be done on an asynchronous basis.

Now, as I stated in my last e-mail on this thread my standpoint is that whatever solution we go for - no matter what you choose to call it - is that the programming interface should be clean, easy to understand and in cohesion with the rest of the programming environment. "bsd" is anything but this.