@swift-server/stakeholders any opinions of this as a very early implementation of an API to create/start the HTTP Server itself?

I've updated the PR to rename SimpleHTTPServer to HTTPServer, and I've added a default initializer to HTTPServer. More feedback very welcome.

Question for people: do we want to mark HTTPServer as final?

Personally, I not really sure what universal API for initializing http servers should exist. Of course it can cover simple handmade http servers (maybe even both sync and async), but advanced configuration will be problematic and it can't cover http servers what already exist (think about uwsgi, nginx, httpd, ...) - they usually start using configuration file and then pass some control to application.

May be Tests directory is a better place for this HTTPServer?

The aim of the HTTPServer API is to provide a simple out of the box HTTP server, similar to what is provided as part of the core APIs in other languages. That doesn't preclude you putting a HTTP/reverse proxy server infront.

Out of the box http server is good feature but it should be placed in a separate module to not inject additional dependencies into API's one.

Some more questions:

• Do we really need HTTPServing protocol in this case?
• Which one sync or async (both?) http server should come out of the box?

Yes, the HTTPServing protocol is somewhat superfluous given that its really a concrete implementation.

The intent is to provide an async server out of the box. Its hard to argue that the current and future concurrency model for Swift is not async - Dispatch is provided as part of the existing Swift toolchains, and large swathes of the available APIs are async based. Additionally both the Swift 5 manifesto and the recent async/await proposal points to that as the ongoing direction.

Its hard to argue that the current and future concurrency model for Swift is not async

I agree with that, if you are willing to add 'default' ;-) What is wrong with using Swift to write Apache modules, Android stuff, Outlook plugins, or whatever. Nothing. There is little use in tying Swift to a specific setup.

Dispatch is provided as part of the existing Swift toolchains

And those are super limited. Even the Linux implementation is, well, you probably know the issues much better than I do ;-)

Dispatch is in fact a major issue with secondary toolchains (BSD? Raspi? Other IoT etc).

Also specifically for Dispatch, that Tesla^d^d^d^d Google guy on Concurrency in Swift:

The one problem I anticipate with GCD is that it doesn't scale well enough: server developers in particular will want to instantiate hundreds of thousands of actors in their application

That is something which is bothering me as well (but may not affect the core choice for async, i.e. one could use libuv too).

In general my opinion is that having a basic http server lib is nice in any case (I really don't expect that serious server frameworks are going to use this for plenty of reasons). So maybe lets just get this done, but lets try to make it so, that other implementations can still use the same or similar API.

Thanks Helge. I'm going to merge this as-is: the remaining questions are around the need for the HTTPServing protocol and whether or not to mark as final, which I think we can deal with separately.

@seabaylea

Its hard to argue that the current and future concurrency model for Swift is not async

but from what I can tell the current implementation is synchronous and blocking. Will this change soon? I think we should definitely do that before pitching to swift-evo.

@weissi that's the intent, yes - any help you can provide would be greatly appreciated!