[swift-server-dev] Next HTTP API meeting

[Helge Heß]

Hi Ben,

I guess I can give an example of what I think Logan may also have in mind.

For mod_swift I ported a trimmed down version of the Noze.io Express module to Apache. Originally that was using a concrete implementation for the incoming request (the ApacheExpress.IncomingMessage class).
After doing the work I found it stupid to have two Express implementations flying around. The `ApacheExpress` module (middleware etc) didn't really have many Apache dependencies, it still just works on top of the request and response. So I figured I can separate out the whole Express functionality just by making IncomingMessage/ServerResponse protocols:

  https://github.com/AlwaysRightInstitute/mod_swift/blob/master/ThirdParty/ExExpress/Sources/http/IncomingMessage.swift#L6

Now I have a server agnostic `ExExpress` module which has zero Apache dependencies and could be used by any other framework implementing the `ExExpress.IncomingMessage` protocol.

And the `ApacheExpress` is now a pretty small module which is just concerned with the Apache mapping of the IncomingMessage protocol:

  https://github.com/AlwaysRightInstitute/mod_swift/blob/master/ApacheExpress/Sources/ApacheIncomingMessage.swift#L11


Now I think there is the hope that the Swift Server Project would provide server agnostic protocols for Request/Response which can be used as a common basis by module writers. And which would then work for Kitura or Perfect etc.

Do you have another suggestion on how this could be solved w/o protocols? Just switch implementations by switching packages? ;-]


Note that there may be a difference between the types used for higher level middleware-like processing and the entities produced by a low level parser. The low level parser could still e.g. produce a struct representing an HTTP message head, which is then used as a value by the higher level object.
Or you could give the parser a factory which directly feeds in parsed fields etc, but that may not make a lot of sense from a performance perspective (then rather have a `init(head: HTTPParser.RequestHead)`).

hh

P.S.: The Noze.io vs mod_swift ‘Express module' is also a pretty good demo on the difficulties sharing an implementation between different concurrency models (ExExpress is completely sync and doesn’t require any @escaping callbacks, while Noze.io is the exact opposite of that).

> On 22 Mar 2017, at 14:19, Ben Cohen <ben_cohen at apple.com> wrote:
> 
> 
>> On Mar 20, 2017, at 11:11 PM, Logan Wright via swift-server-dev <swift-server-dev at swift.org> wrote:
>> 
>> I'd personally like to see us more explicitly explore protocols, I haven't seen anything so far that actually requires a concrete model and would perhaps be an easier way for us to reach consensus.
> 
> Hi Logan,
> 
> What is it about protocols that you feel would help here? In general, the relationship between concrete implementations and protocols should be that the former comes first, then the latter. Start with a concrete type, then as you move to multiple diverse implementations, factor out the common things that unify those types.
> 
> Protocols in Swift exist primarily to allow code to operate on multiple different concrete implementations simultaneously – either with generics as constraints, or as existentials. In this case, there is no clear reason why someone would want to write code that handles two separate implementations of an HTTP API at the same time within a single program. Protocols are not necessary in order to “swap” implementation A for implementation B. All that is needed for this is that the two implementations be source compatible i.e. have the same method signatures (protocols are a way of helping enforce that, but there are other less performance-consequential ways of doing it too).
> 
> Now, it may be that a need does emerge as the design takes shape to have separate types, say, for different kinds of HTTP connections, that might need to be handled by the same program and have to be unified via a protocol to enable handling code to be shared across both. But this protocol should be discovered through the process of looking at the common features the different concrete types have, rather than designed up front.
> 
> Cheers,
> Ben
> 
> 

-------------- 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/20170322/2a738463/attachment.sig>