[swift-server-dev] HTTP API v0.1.0
me at swizzlr.co
Tue Oct 3 15:38:05 CDT 2017
It’s my impression that this API will be the metaphorical engine and drivetrain for the cars we build.
Sent from my iPhone
> On Oct 3, 2017, at 15:59, Helge Heß via swift-server-dev <swift-server-dev at swift.org> wrote:
>> On 3. Oct 2017, at 19:55, Vladimir.S via swift-server-dev <swift-server-dev at swift.org> wrote:
>> Thank you Chris and others for all of this job, I believe HTTP API is very important for Swift future.
>> For example, the 'echo' server written in Node.js I googled fast:
> Googling fast is not always Googling well ;-)
> (Note that this is not the suggested Node.js style anymore either. To support back pressure, you are supposed to use readable events. This is a good intro on the relevant stuff: https://github.com/substack/stream-handbook)
> Anyways, I think this effort is not about streams at all, it is about providing a basic HTTP server library, not a complete framework like Node.js.
> The intention is that you would build an actual developer-facing framework on top of that. And while I somewhat dislike the proposed API, I think it is good enough as a basis to layer another API on top of it ;-)
>> On 3. Oct 2017, at 21:20, Georgios Moschovitis via swift-server-dev <swift-server-dev at swift.org> wrote:
>> Indeed, I also find the HTMLBodyProcessing interface peculiar.
>> A ‘stream’ based interface like NodeJS looks more familiar to me.
>> Maybe we should revisit the API after the outcome of the concurrency/async-await/reactive-streams
>> design process?
> I think that the interface is weird is not necessarily a blocker, as long as you can build an async stream based interface on top of it, and that seems to be a given.
> The concurrency/async-await may make stuff nicer, but it wouldn’t change the actual implementation?
> What I read about `reactive-streams` may not be (very well) suitable for I/O. To me it sounds a little like Node streams v1 vs v3. Do you have a link explaining this stuff? I’m interested in learning more about this (is this a Swift 5 proposal or something?)
> P.S.: If you want Node.js like (v3) streams, you may consider having a look at my Noze.io project (http://noze.io). It is an attempt to reimplement the Node streaming features in Swift, while preserving type safety. Well, and enhance it to streams of arbitrary objects (Node also supports that, kinda, but you loose all the batch processing/buffering features, making it kinda non-sensical)
> P.S.2.: I didn’t look through it, but the demo implementation looks very weird to me. It seems to use DispatchQueues as if they are threads, and in combination w/ that, locks?! I’m probably unfair, I just had a cursory look :->
> swift-server-dev mailing list
> swift-server-dev at swift.org
More information about the swift-server-dev