[swift-server-dev] Database API/Framework

[Chris Bailey]

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20161026/f87a0fbc/attachment.html>