[swift-server-dev] Next HTTP API meeting

[Dan Appel]

I think the most important aspect of these APIs that hasn't been mentioned
is that they have to work for everyone. If they do not fit all the
requirements out of the box, then they should at the very least be
wrappable into doing so. In the case of value vs reference types, any value
type can be made a reference type (via inout or a wrapper class) whereas
the other way around is simply not possible. If higher level frameworks
want reference type behavior because that's what they believe their users
expect, then they should be free to do that while still taking advantage of
these APIs. With that in mind I'd argue that it really doesn't matter which
is more correct, but rather which is both flexible and performant.

Dan

On Wed, Mar 29, 2017 at 10:54 AM Helge Heß via swift-server-dev <
swift-server-dev at swift.org> wrote:

On 29. Mar 2017, at 19:14, Johannes Weiß <johannesweiss at apple.com> wrote:
>> And we didn’t even discuss body streams yet, which I still find much
more interesting due to the implications they can have on the I/O model :-)
Paulo already mentioned the possible need for two APIs (async/sync), which
matches my experience.
>
> As per my email where I sketch what we use internally, we only have an
async API. We have higher-level stuff on that and some does actually have
sync APIs but why do you think we need both a sync and an async API? If
someone wants a sync web framework, that's pretty simple to put on top of
an async API.

I’ve been thinking a lot about that lately (since well, one of my projects
Noze.io is async to the core while my other, mod_swift, is completely sync
for practical purposes). I do not think that it is easy at all to put a
sync API on top of an async one. But maybe you can enlighten me :-)

Yes, you can use a DispatchSemaphore to serialise the access and make GCD
stuff work within sync environments, but as far as I can see this can’t be
done in an automagic way right now. It would be cool if GCD would support
that, something like a DispatchMain(), but more like
WaitForEverythingScheduledFromThisThread().

The other thing is that async (not NIO) essentially requires @escaping
closures while sync stuff often doesn’t. @escaping is a pretty big big
overhead.

You can have the same user-facing API, like:

  readFile(“/etc/passwd”) { data in
  }

but in a sync framework that would be

  func readFile(_ p: String, cb: (Data)->Void)

in an async framework it would be

  func readFile(_ p: String, cb: @escaping (Data)->Void)

Would be trivial with a #define in C, but due to the excellence of Swift,
this is not that easy to do w/o copying large amounts of code ;-> (apart
from always doing @escaping and live with copying the stack to the heap,
adding ARC etc, which is plain lame).

Plus the error reporting issue (throws vs (error, result)).


>  So I'd argue we should only have an async API for the HTTP stuff this
group proposes.

That sounds OK to *me*. If people want to do other stuff, they still can
(libmill and such), it will just perform worse ...

hh

_______________________________________________
swift-server-dev mailing list
swift-server-dev at swift.org
https://lists.swift.org/mailman/listinfo/swift-server-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20170329/c5bb450b/attachment.html>