[swift-server-dev] Sockets API

[Helge Heß]

On 27 Oct 2016, at 00:12, Logan Wright via swift-server-dev <swift-server-dev at swift.org> wrote:
> Sticking w/ the direction of the doc and working upwards, TCP and general socket work seems to be a natural starting point to work with.
> - Logan

I think people first had to figure out what this is all about. Maybe a swift-server-discuss mailing list is still valuable.


# Starting Point: Sockets

First of all I wonder whether this really belongs into Foundation, not swift-server-dev? It sounds like a generic Foundation feature which is as useful on the client. Or is it going to be developed here and moved over when ready?

Anyways, so what do people expect from a low level sockets API. There are a lot of design choices. To name a few:

1) Should it be synchronous (potentially w/ a non-blocking mode) and
   essentially just wrapping the Posix (and later) API?

2) Should it be asynchronous?

  - does everyone agree that async I/O would be driven by
    libdispatch channels?
    - and that data would be handed back-n-forth using DispatchData?

  - if it is async, ‘Swifty’ API for error handling does not really
    exist, i.e. no throws/try etc
    - so what should error handling look like?

  - should it use escaping closures for callbacks or delegates

3) Do you really want just a Socket, or is what you really want
   a (byte) stream framework?

  - there are some specifics to sockets (timeouts, connects and
    such), but the core of reading/writing(/encrypting/hashing/..)
    byte blocks/vectors is a general concept
    - this also affects TLS support (which wraps the reading/writing)

  - in the context of a potential core HTTP module, would requests
    and responses be exposed as streams with the same API?
    - think about chunked and WebSocket/Upgrade here
    - or would the HTTP API be completely separate?

  - would you want to have piping? (say, stream a file to a socket
    and through a zip stream)
    - would it handle back pressure?
    - consider optimisations for FD based streams (to use sendfile()
      and such)

4) Does it need String support or just bytes?

  - in a way java.io.Reader/Writer vs java.io.xyzStream


I would be interested to hear some ideas on where people think this would be going :-)

hh

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20161027/f75131ae/attachment.sig>