[swift-server-dev] Database API/Framework

Gregor Milos gmilos at apple.com
Wed Oct 26 10:31:34 CDT 2016 

Additional advantage of a standardised APIs+implementation is standardised license. MIT (for NGINX http_parser) is not a big deal, but the more dependencies you're pulling into your app, the harder it's to track it all.


Some more comments inline:

> On 26 Oct 2016, at 15:39, Helge Heß via swift-server-dev <swift-server-dev at swift.org> wrote:
> 
> Hi Gregor,
> 
> On 26 Oct 2016, at 15:35, Gregor Milos <gmilos at apple.com> wrote:
>> Expand on Chris's answer, modern languages used on server side come with abstractions native to their language.
> 
> now that is a pretty bold claim. C, C++, Java, JavaScript, Ruby and Objective-C, don’t. Python does, but few use that. But yes, Go seems to come with one … :-)
> 
>> * Netty (defacto standard Java net lib)
> 
> Hu?! Since when is Netty the `defacto standard Java net lib`? Netty is a prime example of just being one of many options coming as a 3rd party package (being a good one for sure).

It's all about the definition of "modern" ;). More seriously though, the core of my point is that good APIs are invariably designed for the language in question, rather than foreign imports. The distribution model (compiler/stdlib/common libraries/package manager) is orthogonal. At this point I don't think it's clear how we are going to deliver the implementation of APIs designed by this work-group either. https://swift.org/server-apis/ talks about the process somewhat, but where the code belongs will largely depend on what it evolves to look like.

> 
> 
> OK OK, nitpicking aside, so the goal this:
> 
>> Our task should be to design an API that works well in Swift.
> 
> Understood. So the plan is indeed to replace the kernel of the HL frameworks with a common Swift `http` server module. A peer to https://golang.org/pkg/net/http/. Fair enough.
> 
> 
>> Node's http_parser is "just" an example of an API and a possible way of accelerating the implementation of Swift's HTTP parser.
> 
> The http_parser is not just 'an example of an API', it is an actual implementation of a HTTP parser which can be used from Swift right away. And not a bad one :-) I guess my original question was why people invent their own instead of just using the implementations directly accessible already. Same for OpenSSL, Expat, etc. I really like the Swift-C mapping and how convenient it is to use.

Yes, it can be used from Swift and yes, it's a good parser. But the fact it's not a Swift HTTP parser is immediately obvious. We always wrap it in layer of Swift that deals with all the UnsafeMutablePointers, state management and something that exposes API conforming to https://swift.org/documentation/api-design-guidelines/.

Hope this all makes sense.
Gregor

> 
> Unless of course we are not talking about providing core support for HL frameworks (which provide the nice API of their choice to backend developers), but for directly providing nice APIs to backend developers as part of the Swift project. (so that they don’t have to grab say Kitura just to build a small micro service).
> 
> 
> But I think I got you, you want to wrap that kind of thing (or rewrite in pure Swift) in a nicer, Swiftier API. Thanks for clarifying that.
> 
> hh
> 
> 
>>> On 26 Oct 2016, at 12:39, Chris Bailey via swift-server-dev <swift-server-dev at swift.org> wrote:
>>> 
>>> Hi Helge:
>>> 
>>> As the initial target areas are low-level function, yes, each of the frameworks has an implementation of most of them today. Those implementations tend to be limited in a number of ways:
>>> 	• C libraries are often used directly (via a modulemap)
>>> This means that there's no general "Swift API" that developers can use - you have to interface with the C APIs directly and deal with Unsafe/OpaquePointers etc. Ideally we want Swift developers to only have to write Swift code
>>> 	• Where a Swift API wraps a C library its generally for a specific use case
>>> As the framework teams have a very specific use case - using it in their framework - the APIs are very directed to what they need to do, rather than being general purpose for a wider set of use cases
>>> 	• There's multiple, similar, packages
>>> Most frameworks have their own server socket implementation (mostly by calling Glibc and Darwin), HTTP parser implementation, etc. Not only does this mean we can consolidate the efforts on a single implementation, but it means that anyone wanting to add additional platform support (like Windows) only has to do so once.
>>> 
>>> Chris
>>> 
>>> 
>>> 
>>> 
>>> From:        Helge Heß via swift-server-dev <swift-server-dev at swift.org>
>>> To:        swift-server-dev at swift.org
>>> Date:        25/10/2016 19:57
>>> Subject:        Re: [swift-server-dev] Database API/Framework
>>> Sent by:        swift-server-dev-bounces at swift.org
>>> 
>>> 
>>> 
>>> Hi Chris,
>>> 
>>> it is a little unclear what the scope of the group is. Presumably you have some very specific things in mind?
>>> 
>>> Of course we’ve seen https://swift.org/server-apis/#focus-areas. But what does it actually mean? :-) Looking at it:
>>> - base networking: TCP/UDP, DNS. Covered already by libdispatch and the OS’ses?
>>> - security: OpenSSL? or some wrapper around both, CC and OpenSSL?
>>> - provide low level HTTP parsing: http_parser? Is anyone using something
>>> else?
>>> All that seems kinda covered/standard already? Unless maybe you include non-Unix stuff like Windows.
>>> 
>>> Is this primarily for things like providing a standardised ’swiftier' OpenSSL wrapper (similar to how Objective-GCD wraps libdispatch)?
>>> Or would that just be module maps which are shipped by default with Swift and hence can be relied on by all frameworks?
>>> 
>>> But maybe I’m just a little too impatient :->
>>> 
>>> hh
>>> 
>>>> On 25 Oct 2016, at 20:41, Chris Bailey via swift-server-dev <swift-server-dev at swift.org> wrote:
>>>> 
>>>> Hi Ron:
>>>> 
>>>> As you say, that's outside of the scope of the work group, however I do think its a valuable area that the various existing web framework groups might be interested in collaborating on. Having a common, recognized framework that the database providers or third parties would be interested in writing database drivers for would be a huge step forward.
>>>> 
>>>> I know that Vapor has its Fluent ORM framework, and that its an area that the Kitura team are looking at as well, so your post might kick-start some wider discussion.
>>>> 
>>>> Chris
>>>> 
>>>> 
>>>> 
>>>> 
>>>> From:        Ron Olson via swift-server-dev <swift-server-dev at swift.org>
>>>> To:        swift-server-dev at swift.org
>>>> Date:        25/10/2016 18:54
>>>> Subject:        [swift-server-dev] Database API/Framework
>>>> Sent by:        swift-server-dev-bounces at swift.org
>>>> 
>>>> 
>>>> 
>>>> Hi all-
>>>> 
>>>> I've been working with Swift more on Linux than macOS and am very
>>>> excited to see the formation of this group. Looking at the server api
>>>> workgroup's focus, I notice it's primarily low-level interaction with
>>>> the operating system. When might it be a good time to bring up the
>>>> possibility of creating a database-specific framework for those folks
>>>> who want to work directly with Postgres, MySQL, even DB2 and Oracle; I'm
>>>> thinking a JDBC-inspired framework that drivers could be written
>>>> against.
>>>> 
>>>> Thanks,
>>>> 
>>>> Ron
>>>> _______________________________________________
>>>> swift-server-dev mailing list
>>>> swift-server-dev at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-server-dev
>>>> 
>>>> 
>>>> _______________________________________________
>>>> swift-server-dev mailing list
>>>> swift-server-dev at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-server-dev
>>> 
>>> _______________________________________________
>>> swift-server-dev mailing list
>>> swift-server-dev at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-server-dev
>>> 
>>> 
>>> _______________________________________________
>>> swift-server-dev mailing list
>>> swift-server-dev at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-server-dev
>> 
> 
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-server-dev

More information about the swift-server-dev mailing list