HTTP webserver protocol's


(Coen Wessels) #1

Since the linux port is available everybody is implementing their own HTTP
server framework https://github.com/search?utf8=✓&q=http+language%3Aswift.
I think introducing a default http web server protocol(swift protocol) in
the stdlib, something like rack(ruby) or plug(elixir), would prevent a lot
of fragmentation in interfaces.


(John Siracusa) #2

The very first thing I considered writing in Swift is an implementation of
Plack (http://plackperl.org/). It seems like every language benefits from
having something like this (Rack in Ruby, WSGI in Python, etc.), even if
only to insulate web applications from the web server implementation. I'm
not sure if a language benefits from having 20 things like this, at least
in the long run…

-John

···

On Mon, Dec 7, 2015 at 9:08 AM, Coen Wessels via swift-evolution < swift-evolution@swift.org> wrote:

Since the linux port is available everybody is implementing their own HTTP
server framework https://github.com/search?utf8=✓&q=http+language%3Aswift.
I think introducing a default http web server protocol(swift protocol) in
the stdlib, something like rack(ruby) or plug(elixir), would prevent a lot
of fragmentation in interfaces.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Brent Royal-Gordon) #3

Since the linux port is available everybody is implementing their own HTTP server framework https://github.com/search?utf8=✓&q=http+language%3Aswift. I think introducing a default http web server protocol(swift protocol) in the stdlib, something like rack(ruby) or plug(elixir), would prevent a lot of fragmentation in interfaces.

This kind of thing seems to be out of scope for the core Swift project, just as the request for a common logging system was.

(However, I took a crack at this problem a few months ago, and managed to get something running on GCDWebServer: https://github.com/brentdax/WebResponder)

···

--
Brent Royal-Gordon
Architechies


(Lukas Stabe) #4

The [Nest project](https://github.com/nestproject/Nest) seems to aim to be something like this.

While I agree that a Rack/WSGI/Plack equivalent would be benificial to have, I don’t think it fits the current goals of the stdlib (providing basic data structures and algorithms) for now.

Lukas

···

On 07 Dec 2015, at 16:27, John Siracusa via swift-evolution <swift-evolution@swift.org> wrote:

The very first thing I considered writing in Swift is an implementation of Plack (http://plackperl.org/). It seems like every language benefits from having something like this (Rack in Ruby, WSGI in Python, etc.), even if only to insulate web applications from the web server implementation. I'm not sure if a language benefits from having 20 things like this, at least in the long run…

-John

On Mon, Dec 7, 2015 at 9:08 AM, Coen Wessels via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Since the linux port is available everybody is implementing their own HTTP server framework https://github.com/search?utf8=✓&q=http+language%3Aswift <https://github.com/search?utf8=✓&q=http+language%3Aswift>. I think introducing a default http web server protocol(swift protocol) in the stdlib, something like rack(ruby) or plug(elixir), would prevent a lot of fragmentation in interfaces.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Simon Pilkington) #5

I agree that things like this are seperate to the stdlib but I think it would be preferable that they be controlled as part the Swift project. If you look at Java EE and their JSR specs, they are authoritative because they are part of the platform and not a loosely coupled side project. This is not to say they can’t or shouldn’t start out as side projects but I think there should be some process for bringing them in to be defined as part the Swift project.

···

On 7 Dec 2015, at 8:24 AM, Lukas Stabe via swift-evolution <swift-evolution@swift.org> wrote:

The [Nest project](https://github.com/nestproject/Nest) seems to aim to be something like this.

While I agree that a Rack/WSGI/Plack equivalent would be benificial to have, I don’t think it fits the current goals of the stdlib (providing basic data structures and algorithms) for now.

Lukas

On 07 Dec 2015, at 16:27, John Siracusa via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

The very first thing I considered writing in Swift is an implementation of Plack (http://plackperl.org/). It seems like every language benefits from having something like this (Rack in Ruby, WSGI in Python, etc.), even if only to insulate web applications from the web server implementation. I'm not sure if a language benefits from having 20 things like this, at least in the long run…

-John

On Mon, Dec 7, 2015 at 9:08 AM, Coen Wessels via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Since the linux port is available everybody is implementing their own HTTP server framework https://github.com/search?utf8=✓&q=http+language%3Aswift <https://github.com/search?utf8=✓&q=http+language%3Aswift>. I think introducing a default http web server protocol(swift protocol) in the stdlib, something like rack(ruby) or plug(elixir), would prevent a lot of fragmentation in interfaces.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Simon Pilkington) #6

I agree that things like this are seperate to the stdlib but I think it would be preferable that they be controlled as part the Swift project. If you look at Java EE and their JSR specs, they are authoritative because they are part of the platform and not a loosely coupled side project. This is not to say they can’t or shouldn’t start out as side projects but I think there should be some process for bringing them in to be defined as part the Swift project.

···

On 7 Dec 2015, at 8:24 AM, Lukas Stabe via swift-evolution <swift-evolution@swift.org> wrote:

The [Nest project](https://github.com/nestproject/Nest) seems to aim to be something like this.

While I agree that a Rack/WSGI/Plack equivalent would be benificial to have, I don’t think it fits the current goals of the stdlib (providing basic data structures and algorithms) for now.

Lukas

On 07 Dec 2015, at 16:27, John Siracusa via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

The very first thing I considered writing in Swift is an implementation of Plack (http://plackperl.org/). It seems like every language benefits from having something like this (Rack in Ruby, WSGI in Python, etc.), even if only to insulate web applications from the web server implementation. I'm not sure if a language benefits from having 20 things like this, at least in the long run…

-John

On Mon, Dec 7, 2015 at 9:08 AM, Coen Wessels via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Since the linux port is available everybody is implementing their own HTTP server framework https://github.com/search?utf8=✓&q=http+language%3Aswift <https://github.com/search?utf8=✓&q=http+language%3Aswift>. I think introducing a default http web server protocol(swift protocol) in the stdlib, something like rack(ruby) or plug(elixir), would prevent a lot of fragmentation in interfaces.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Paul Cantrell) #7

I wouldn't hold up J2EE and associated JSR specs for associated utilities as an example of success.

J2EE’s history is largely one of failed standardization efforts: specs that suffered from being designed in a vacuum, being designed by committee, or being unable to keep up with evolving insights, needs, and expectations.

The most successful API standardization JSRs have tended to be ones that abstracted third-party projects that already developed and honed _outside_ the JSR process. The spectacular failure of Entity Beans and their wholesale replacement by Hibernate is a prime example, but not the only one.

The core team’s phase 3 goals sound right to me: achieve core stability before expanding the domain of what is “core.”

There are still important problems and gaps with the language’s semantics to be solved.

Cheers,

Paul

···

On Dec 7, 2015, at 11:16 AM, Simon Pilkington via swift-evolution <swift-evolution@swift.org> wrote:

I agree that things like this are seperate to the stdlib but I think it would be preferable that they be controlled as part the Swift project. If you look at Java EE and their JSR specs, they are authoritative because they are part of the platform and not a loosely coupled side project. This is not to say they can’t or shouldn’t start out as side projects but I think there should be some process for bringing them in to be defined as part the Swift project.

On 7 Dec 2015, at 8:24 AM, Lukas Stabe via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

The [Nest project](https://github.com/nestproject/Nest) seems to aim to be something like this.

While I agree that a Rack/WSGI/Plack equivalent would be benificial to have, I don’t think it fits the current goals of the stdlib (providing basic data structures and algorithms) for now.

Lukas

On 07 Dec 2015, at 16:27, John Siracusa via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

The very first thing I considered writing in Swift is an implementation of Plack (http://plackperl.org/). It seems like every language benefits from having something like this (Rack in Ruby, WSGI in Python, etc.), even if only to insulate web applications from the web server implementation. I'm not sure if a language benefits from having 20 things like this, at least in the long run…

-John

On Mon, Dec 7, 2015 at 9:08 AM, Coen Wessels via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Since the linux port is available everybody is implementing their own HTTP server framework https://github.com/search?utf8=✓&q=http+language%3Aswift <https://github.com/search?utf8=✓&q=http+language%3Aswift>. I think introducing a default http web server protocol(swift protocol) in the stdlib, something like rack(ruby) or plug(elixir), would prevent a lot of fragmentation in interfaces.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Simon Pilkington) #8

I wouldn't hold up J2EE and associated JSR specs for associated utilities as an example of success.

J2EE’s history is largely one of failed standardization efforts: specs that suffered from being designed in a vacuum, being designed by committee, or being unable to keep up with evolving insights, needs, and expectations.

I completely agree, particularly on the specifics. I definitely wasn’t trying to hold the JSR specs as the gold standard of what should be done but rather highlighting that there are advantages - particularly in some large enterprise - for such formalisation.

The most successful API standardization JSRs have tended to be ones that abstracted third-party projects that already developed and honed _outside_ the JSR process. The spectacular failure of Entity Beans and their wholesale replacement by Hibernate is a prime example, but not the only one.

True and that is really how such a process would ideally work - as an example, JSR 330 taking a lot of a dependency injection work that projects such as Spring had baked externally and (mostly successfully) formalising it more broadly.

The core team’s phase 3 goals sound right to me: achieve core stability before expanding the domain of what is “core.”

There are still important problems and gaps with the language’s semantics to be solved.

Absolutely and I think https://github.com/apple/swift-evolution#out-of-scope now strikes the correct balance between short term focus and long term evolution.

Cheers,
Simon

···

On 7 Dec 2015, at 11:09 AM, Paul Cantrell <cantrell@pobox.com> wrote:

Cheers,

Paul

On Dec 7, 2015, at 11:16 AM, Simon Pilkington via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I agree that things like this are seperate to the stdlib but I think it would be preferable that they be controlled as part the Swift project. If you look at Java EE and their JSR specs, they are authoritative because they are part of the platform and not a loosely coupled side project. This is not to say they can’t or shouldn’t start out as side projects but I think there should be some process for bringing them in to be defined as part the Swift project.

On 7 Dec 2015, at 8:24 AM, Lukas Stabe via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

The [Nest project](https://github.com/nestproject/Nest) seems to aim to be something like this.

While I agree that a Rack/WSGI/Plack equivalent would be benificial to have, I don’t think it fits the current goals of the stdlib (providing basic data structures and algorithms) for now.

Lukas

On 07 Dec 2015, at 16:27, John Siracusa via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

The very first thing I considered writing in Swift is an implementation of Plack (http://plackperl.org/). It seems like every language benefits from having something like this (Rack in Ruby, WSGI in Python, etc.), even if only to insulate web applications from the web server implementation. I'm not sure if a language benefits from having 20 things like this, at least in the long run…

-John

On Mon, Dec 7, 2015 at 9:08 AM, Coen Wessels via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Since the linux port is available everybody is implementing their own HTTP server framework https://github.com/search?utf8=✓&q=http+language%3Aswift <https://github.com/search?utf8=✓&q=http+language%3Aswift>. I think introducing a default http web server protocol(swift protocol) in the stdlib, something like rack(ruby) or plug(elixir), would prevent a lot of fragmentation in interfaces.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(ChanMaxthon) #9

I would suggest against implementing HTTP protocol directly unless you are willing to tackle complexities like TLS, HTTP/2 and even supporting other languages directly. We can implement the FastCGI protocol and let the user piece together the final website using a purpose-built Web server software that implements all above like nginx.

FastCGI is a mature protocol so it is safe and stable to track (while HTTP is receiving quick development in both HTTP/2 and TLS layers), has the benefit of being able to be executed on a separate machine from the Web server so vulnerability can be isolated and would be a natural fit for load balancing, and is widely used in hosting other languages like PHP, Python and Perl.

···

Sent from my iPad

On Dec 8, 2015, at 00:24, Lukas Stabe via swift-evolution <swift-evolution@swift.org> wrote:

The [Nest project](https://github.com/nestproject/Nest) seems to aim to be something like this.

While I agree that a Rack/WSGI/Plack equivalent would be benificial to have, I don’t think it fits the current goals of the stdlib (providing basic data structures and algorithms) for now.

Lukas

On 07 Dec 2015, at 16:27, John Siracusa via swift-evolution <swift-evolution@swift.org> wrote:

The very first thing I considered writing in Swift is an implementation of Plack (http://plackperl.org/). It seems like every language benefits from having something like this (Rack in Ruby, WSGI in Python, etc.), even if only to insulate web applications from the web server implementation. I'm not sure if a language benefits from having 20 things like this, at least in the long run…

-John

On Mon, Dec 7, 2015 at 9:08 AM, Coen Wessels via swift-evolution <swift-evolution@swift.org> wrote:
Since the linux port is available everybody is implementing their own HTTP server framework https://github.com/search?utf8=✓&q=http+language%3Aswift. I think introducing a default http web server protocol(swift protocol) in the stdlib, something like rack(ruby) or plug(elixir), would prevent a lot of fragmentation in interfaces.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Lukas Stabe) #10

This kind of thing seems to be out of scope for the core Swift project, just as the request for a common logging system was.

Indeed it is. have a look at the ["Out of scope”-section of the Swift 3.0 development goals](https://github.com/apple/swift-evolution#out-of-scope). it states, among others:

  • Major new Library Functionality: The Swift Standard Library is focused on providing core "language" functionality as well as common datastructures. The "corelibs" projects are focused on providing existing Foundation functionality in a portable way. Major new libraries (e.g. a new Logging subsystem) are best developed as independent projects on GitHub (or elsewhere) and organized with the Swift Package Manager. Beyond Swift 3 we may consider standardizing popular packages or expanding the scope of the project. We will consider minor extensions to the existing feature set.

- Lukas