[swift-server-dev] Database API/Framework

Wed Oct 26 09:39:20 CDT 2016

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).

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.

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
> 

-------------- 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/20161026/edc8b416/attachment.sig>