[swift-evolution] HTTP webserver protocol's

[Paul Cantrell]

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 at 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 at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> The [Nest project](https://github.com/nestproject/Nest <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 at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> The very first thing I considered writing in Swift is an implementation of Plack (http://plackperl.org/ <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 at swift.org <mailto:swift-evolution at 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=%E2%9C%93&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 at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> 
>>> 
>>>  _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>>  _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151207/9b21bd09/attachment.html>