<div dir="ltr">I think there's a lot of good discussion here for different potential directions and various areas that people are excited about. I think while this is valuable, eventually it'd probably be beneficial to put some focus on one or two specific areas. 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.<div><br></div><div>- Logan</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 26, 2016 at 1:01 PM <<a href="mailto:swift-server-dev-request@swift.org">swift-server-dev-request@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send swift-server-dev mailing list submissions to<br class="gmail_msg">
<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
<br class="gmail_msg">
To subscribe or unsubscribe via the World Wide Web, visit<br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-server-dev</a><br class="gmail_msg">
or, via email, send a message with subject or body 'help' to<br class="gmail_msg">
<a href="mailto:swift-server-dev-request@swift.org" class="gmail_msg" target="_blank">swift-server-dev-request@swift.org</a><br class="gmail_msg">
<br class="gmail_msg">
You can reach the person managing the list at<br class="gmail_msg">
<a href="mailto:swift-server-dev-owner@swift.org" class="gmail_msg" target="_blank">swift-server-dev-owner@swift.org</a><br class="gmail_msg">
<br class="gmail_msg">
When replying, please edit your Subject line so it is more specific<br class="gmail_msg">
than "Re: Contents of swift-server-dev digest..."<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
Today's Topics:<br class="gmail_msg">
<br class="gmail_msg">
1. Developing Server APIs for Swift (Chris Bailey)<br class="gmail_msg">
2. Database API/Framework (Ron Olson)<br class="gmail_msg">
3. Re: Database API/Framework (Chris Bailey)<br class="gmail_msg">
4. Re: Database API/Framework (Helge Heß)<br class="gmail_msg">
5. [Bug] Foundation.URL should support semicolon(; ) appearing<br class="gmail_msg">
in URL path (<a href="mailto:frogcjn@163.com" class="gmail_msg" target="_blank">frogcjn@163.com</a>)<br class="gmail_msg">
6. Re: Database API/Framework (Paulo Faria)<br class="gmail_msg">
7. Re: Database API/Framework (Haris Amin)<br class="gmail_msg">
8. Re: Database API/Framework (Helge Heß)<br class="gmail_msg">
9. Re: Database API/Framework (Ron Olson)<br class="gmail_msg">
10. Re: [Bug] Foundation.URL should support semicolon(; )<br class="gmail_msg">
appearing in URL path (Alex Blewitt)<br class="gmail_msg">
11. Spring and Baratine (Java frameworks) (Rick Mann)<br class="gmail_msg">
12. Lib dispatch and Edge (Tyler Cloutier)<br class="gmail_msg">
13. Why not rely on existing models? (Yoann Gini)<br class="gmail_msg">
14. Re: Why not rely on existing models? (Helge Heß)<br class="gmail_msg">
15. Re: Database API/Framework (Brent Royal-Gordon)<br class="gmail_msg">
16. Re: Why not rely on existing models? (Yoann Gini)<br class="gmail_msg">
17. Re: Why not rely on existing models? (Brent Royal-Gordon)<br class="gmail_msg">
18. Re: Database API/Framework (Helge Heß)<br class="gmail_msg">
19. Re: Why not rely on existing models? (Yoann Gini)<br class="gmail_msg">
20. Re: Database API/Framework (Chris Bailey)<br class="gmail_msg">
21. Re: Database API/Framework (Gregor Milos)<br class="gmail_msg">
22. Re: Database API/Framework (Gregor Milos)<br class="gmail_msg">
23. Re: Database API/Framework (Helge Heß)<br class="gmail_msg">
24. Async I/O in Rust Tokio (Benedikt Terhechte)<br class="gmail_msg">
25. Re: Database API/Framework (Gregor Milos)<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
----------------------------------------------------------------------<br class="gmail_msg">
<br class="gmail_msg">
Message: 1<br class="gmail_msg">
Date: Tue, 25 Oct 2016 18:18:40 +0100<br class="gmail_msg">
From: Chris Bailey <<a href="mailto:BAILEYC@uk.ibm.com" class="gmail_msg" target="_blank">BAILEYC@uk.ibm.com</a>><br class="gmail_msg">
To: <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
Subject: [swift-server-dev] Developing Server APIs for Swift<br class="gmail_msg">
Message-ID:<br class="gmail_msg">
<<a href="mailto:OFF7B5F3A2.286E27A8-ON80258057.005E33D7-80258057.005F17AB@notes.na.collabserv.com" class="gmail_msg" target="_blank">OFF7B5F3A2.286E27A8-ON80258057.005E33D7-80258057.005F17AB@notes.na.collabserv.com</a>><br class="gmail_msg">
<br class="gmail_msg">
Content-Type: text/plain; charset="utf-8"<br class="gmail_msg">
<br class="gmail_msg">
A new project and work group has just been announced, aimed at providing a<br class="gmail_msg">
framework for participants in the community with an interest in building<br class="gmail_msg">
server applications and frameworks to come together to work on providing<br class="gmail_msg">
new Swift APIs.<br class="gmail_msg">
<a href="https://swift.org/blog/server-api-workgroup/" rel="noreferrer" class="gmail_msg" target="_blank">https://swift.org/blog/server-api-workgroup/</a><br class="gmail_msg">
<br class="gmail_msg">
Whilst there is already strong participation from some of the more well<br class="gmail_msg">
know web frameworks, including Kitura, Vapor, Perfect, and Zewo,<br class="gmail_msg">
participation and contribution is open to everyone - whether that's having<br class="gmail_msg">
a requirement or use case you'd like to share, bugs you want to report<br class="gmail_msg">
(once we have code!), code your willing to write, or just your thoughts on<br class="gmail_msg">
what's needed.<br class="gmail_msg">
<br class="gmail_msg">
Chris<br class="gmail_msg">
-------------- next part --------------<br class="gmail_msg">
An HTML attachment was scrubbed...<br class="gmail_msg">
URL: <<a href="https://lists.swift.org/pipermail/swift-server-dev/attachments/20161025/89b49b87/attachment-0001.html" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/pipermail/swift-server-dev/attachments/20161025/89b49b87/attachment-0001.html</a>><br class="gmail_msg">
<br class="gmail_msg">
------------------------------<br class="gmail_msg">
<br class="gmail_msg">
Message: 2<br class="gmail_msg">
Date: Tue, 25 Oct 2016 12:53:56 -0500<br class="gmail_msg">
From: "Ron Olson" <<a href="mailto:tachoknight@gmail.com" class="gmail_msg" target="_blank">tachoknight@gmail.com</a>><br class="gmail_msg">
To: <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
Subject: [swift-server-dev] Database API/Framework<br class="gmail_msg">
Message-ID: <<a href="mailto:014CED77-5B93-4EF1-A089-EF4926CCF47C@gmail.com" class="gmail_msg" target="_blank">014CED77-5B93-4EF1-A089-EF4926CCF47C@gmail.com</a>><br class="gmail_msg">
Content-Type: text/plain; format=flowed<br class="gmail_msg">
<br class="gmail_msg">
Hi all-<br class="gmail_msg">
<br class="gmail_msg">
I've been working with Swift more on Linux than macOS and am very<br class="gmail_msg">
excited to see the formation of this group. Looking at the server api<br class="gmail_msg">
workgroup's focus, I notice it's primarily low-level interaction with<br class="gmail_msg">
the operating system. When might it be a good time to bring up the<br class="gmail_msg">
possibility of creating a database-specific framework for those folks<br class="gmail_msg">
who want to work directly with Postgres, MySQL, even DB2 and Oracle; I'm<br class="gmail_msg">
thinking a JDBC-inspired framework that drivers could be written<br class="gmail_msg">
against.<br class="gmail_msg">
<br class="gmail_msg">
Thanks,<br class="gmail_msg">
<br class="gmail_msg">
Ron<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
------------------------------<br class="gmail_msg">
<br class="gmail_msg">
Message: 3<br class="gmail_msg">
Date: Tue, 25 Oct 2016 19:41:32 +0100<br class="gmail_msg">
From: Chris Bailey <<a href="mailto:BAILEYC@uk.ibm.com" class="gmail_msg" target="_blank">BAILEYC@uk.ibm.com</a>><br class="gmail_msg">
To: Ron Olson <<a href="mailto:tachoknight@gmail.com" class="gmail_msg" target="_blank">tachoknight@gmail.com</a>><br class="gmail_msg">
Cc: <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
Subject: Re: [swift-server-dev] Database API/Framework<br class="gmail_msg">
Message-ID:<br class="gmail_msg">
<<a href="mailto:OFCED025F9.33D57EE8-ON80258057.00662CA1-80258057.0066ADD2@notes.na.collabserv.com" class="gmail_msg" target="_blank">OFCED025F9.33D57EE8-ON80258057.00662CA1-80258057.0066ADD2@notes.na.collabserv.com</a>><br class="gmail_msg">
<br class="gmail_msg">
Content-Type: text/plain; charset="utf-8"<br class="gmail_msg">
<br class="gmail_msg">
Hi Ron:<br class="gmail_msg">
<br class="gmail_msg">
As you say, that's outside of the scope of the work group, however I do<br class="gmail_msg">
think its a valuable area that the various existing web framework groups<br class="gmail_msg">
might be interested in collaborating on. Having a common, recognized<br class="gmail_msg">
framework that the database providers or third parties would be interested<br class="gmail_msg">
in writing database drivers for would be a huge step forward.<br class="gmail_msg">
<br class="gmail_msg">
I know that Vapor has its Fluent ORM framework, and that its an area that<br class="gmail_msg">
the Kitura team are looking at as well, so your post might kick-start some<br class="gmail_msg">
wider discussion.<br class="gmail_msg">
<br class="gmail_msg">
Chris<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
From: Ron Olson via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>><br class="gmail_msg">
To: <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
Date: 25/10/2016 18:54<br class="gmail_msg">
Subject: [swift-server-dev] Database API/Framework<br class="gmail_msg">
Sent by: <a href="mailto:swift-server-dev-bounces@swift.org" class="gmail_msg" target="_blank">swift-server-dev-bounces@swift.org</a><br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
Hi all-<br class="gmail_msg">
<br class="gmail_msg">
I've been working with Swift more on Linux than macOS and am very<br class="gmail_msg">
excited to see the formation of this group. Looking at the server api<br class="gmail_msg">
workgroup's focus, I notice it's primarily low-level interaction with<br class="gmail_msg">
the operating system. When might it be a good time to bring up the<br class="gmail_msg">
possibility of creating a database-specific framework for those folks<br class="gmail_msg">
who want to work directly with Postgres, MySQL, even DB2 and Oracle; I'm<br class="gmail_msg">
thinking a JDBC-inspired framework that drivers could be written<br class="gmail_msg">
against.<br class="gmail_msg">
<br class="gmail_msg">
Thanks,<br class="gmail_msg">
<br class="gmail_msg">
Ron<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
swift-server-dev mailing list<br class="gmail_msg">
<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-server-dev</a><br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
-------------- next part --------------<br class="gmail_msg">
An HTML attachment was scrubbed...<br class="gmail_msg">
URL: <<a href="https://lists.swift.org/pipermail/swift-server-dev/attachments/20161025/59d5ff21/attachment-0001.html" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/pipermail/swift-server-dev/attachments/20161025/59d5ff21/attachment-0001.html</a>><br class="gmail_msg">
<br class="gmail_msg">
------------------------------<br class="gmail_msg">
<br class="gmail_msg">
Message: 4<br class="gmail_msg">
Date: Tue, 25 Oct 2016 20:56:13 +0200<br class="gmail_msg">
From: Helge Heß <<a href="mailto:me@helgehess.eu" class="gmail_msg" target="_blank">me@helgehess.eu</a>><br class="gmail_msg">
To: <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
Subject: Re: [swift-server-dev] Database API/Framework<br class="gmail_msg">
Message-ID: <<a href="mailto:0A3EC83B-E26E-49F3-8EDE-E2B85D6836D1@helgehess.eu" class="gmail_msg" target="_blank">0A3EC83B-E26E-49F3-8EDE-E2B85D6836D1@helgehess.eu</a>><br class="gmail_msg">
Content-Type: text/plain; charset=utf-8<br class="gmail_msg">
<br class="gmail_msg">
Hi Chris,<br class="gmail_msg">
<br class="gmail_msg">
it is a little unclear what the scope of the group is. Presumably you have some very specific things in mind?<br class="gmail_msg">
<br class="gmail_msg">
Of course we’ve seen <a href="https://swift.org/server-apis/#focus-areas" rel="noreferrer" class="gmail_msg" target="_blank">https://swift.org/server-apis/#focus-areas</a>. But what does it actually mean? :-) Looking at it:<br class="gmail_msg">
- base networking: TCP/UDP, DNS. Covered already by libdispatch and the OS’ses?<br class="gmail_msg">
- security: OpenSSL? or some wrapper around both, CC and OpenSSL?<br class="gmail_msg">
- provide low level HTTP parsing: http_parser? Is anyone using something<br class="gmail_msg">
else?<br class="gmail_msg">
All that seems kinda covered/standard already? Unless maybe you include non-Unix stuff like Windows.<br class="gmail_msg">
<br class="gmail_msg">
Is this primarily for things like providing a standardised ’swiftier' OpenSSL wrapper (similar to how Objective-GCD wraps libdispatch)?<br class="gmail_msg">
Or would that just be module maps which are shipped by default with Swift and hence can be relied on by all frameworks?<br class="gmail_msg">
<br class="gmail_msg">
But maybe I’m just a little too impatient :-><br class="gmail_msg">
<br class="gmail_msg">
hh<br class="gmail_msg">
<br class="gmail_msg">
> On 25 Oct 2016, at 20:41, Chris Bailey via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
> Hi Ron:<br class="gmail_msg">
><br class="gmail_msg">
> 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.<br class="gmail_msg">
><br class="gmail_msg">
> 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.<br class="gmail_msg">
><br class="gmail_msg">
> Chris<br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> From: Ron Olson via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>><br class="gmail_msg">
> To: <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
> Date: 25/10/2016 18:54<br class="gmail_msg">
> Subject: [swift-server-dev] Database API/Framework<br class="gmail_msg">
> Sent by: <a href="mailto:swift-server-dev-bounces@swift.org" class="gmail_msg" target="_blank">swift-server-dev-bounces@swift.org</a><br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> Hi all-<br class="gmail_msg">
><br class="gmail_msg">
> I've been working with Swift more on Linux than macOS and am very<br class="gmail_msg">
> excited to see the formation of this group. Looking at the server api<br class="gmail_msg">
> workgroup's focus, I notice it's primarily low-level interaction with<br class="gmail_msg">
> the operating system. When might it be a good time to bring up the<br class="gmail_msg">
> possibility of creating a database-specific framework for those folks<br class="gmail_msg">
> who want to work directly with Postgres, MySQL, even DB2 and Oracle; I'm<br class="gmail_msg">
> thinking a JDBC-inspired framework that drivers could be written<br class="gmail_msg">
> against.<br class="gmail_msg">
><br class="gmail_msg">
> Thanks,<br class="gmail_msg">
><br class="gmail_msg">
> Ron<br class="gmail_msg">
> _______________________________________________<br class="gmail_msg">
> swift-server-dev mailing list<br class="gmail_msg">
> <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
> <a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-server-dev</a><br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> _______________________________________________<br class="gmail_msg">
> swift-server-dev mailing list<br class="gmail_msg">
> <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
> <a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-server-dev</a><br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
------------------------------<br class="gmail_msg">
<br class="gmail_msg">
Message: 5<br class="gmail_msg">
Date: Wed, 26 Oct 2016 03:09:33 +0800<br class="gmail_msg">
From: <a href="mailto:frogcjn@163.com" class="gmail_msg" target="_blank">frogcjn@163.com</a><br class="gmail_msg">
To: <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
Subject: [swift-server-dev] [Bug] Foundation.URL should support<br class="gmail_msg">
semicolon(; ) appearing in URL path<br class="gmail_msg">
Message-ID: <<a href="mailto:22A5614E-C6ED-47DD-A190-917C49422D02@163.com" class="gmail_msg" target="_blank">22A5614E-C6ED-47DD-A190-917C49422D02@163.com</a>><br class="gmail_msg">
Content-Type: text/plain; charset=us-ascii<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<a href="http://host/book;id=1/page;2/" rel="noreferrer" class="gmail_msg" target="_blank">http://host/book;id=1/page;2/</a><br class="gmail_msg">
<br class="gmail_msg">
this URL is a valid URL, but URLComponents will ruin it with %3B<br class="gmail_msg">
<a href="http://host/book%3Bid=1/page%3B2/" rel="noreferrer" class="gmail_msg" target="_blank">http://host/book%3Bid=1/page%3B2/</a><br class="gmail_msg">
<br class="gmail_msg">
Since Swift Server is coming out, this bug should be solved.<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
------------------------------<br class="gmail_msg">
<br class="gmail_msg">
Message: 6<br class="gmail_msg">
Date: Tue, 25 Oct 2016 17:20:23 -0200<br class="gmail_msg">
From: Paulo Faria <<a href="mailto:paulo@zewo.io" class="gmail_msg" target="_blank">paulo@zewo.io</a>><br class="gmail_msg">
To: Helge Heß <<a href="mailto:me@helgehess.eu" class="gmail_msg" target="_blank">me@helgehess.eu</a>><br class="gmail_msg">
Cc: <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
Subject: Re: [swift-server-dev] Database API/Framework<br class="gmail_msg">
Message-ID: <<a href="mailto:78032B27-2CF6-480A-8B21-9EE4C10B8161@zewo.io" class="gmail_msg" target="_blank">78032B27-2CF6-480A-8B21-9EE4C10B8161@zewo.io</a>><br class="gmail_msg">
Content-Type: text/plain; charset=utf-8<br class="gmail_msg">
<br class="gmail_msg">
Hello, Helge.<br class="gmail_msg">
<br class="gmail_msg">
Yes, most of the things we’ll cover are already provided by some frameworks, but having an official library joining efforts will be great for the community. We’ll provide full-fledged Swift libraries for the topics mentioned. How they’re going to be developed it’s still to be decided.<br class="gmail_msg">
<br class="gmail_msg">
Cheers,<br class="gmail_msg">
Paulo<br class="gmail_msg">
<br class="gmail_msg">
> On Oct 25, 2016, at 4:56 PM, Helge Heß via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
> Hi Chris,<br class="gmail_msg">
><br class="gmail_msg">
> it is a little unclear what the scope of the group is. Presumably you have some very specific things in mind?<br class="gmail_msg">
><br class="gmail_msg">
> Of course we’ve seen <a href="https://swift.org/server-apis/#focus-areas" rel="noreferrer" class="gmail_msg" target="_blank">https://swift.org/server-apis/#focus-areas</a>. But what does it actually mean? :-) Looking at it:<br class="gmail_msg">
> - base networking: TCP/UDP, DNS. Covered already by libdispatch and the OS’ses?<br class="gmail_msg">
> - security: OpenSSL? or some wrapper around both, CC and OpenSSL?<br class="gmail_msg">
> - provide low level HTTP parsing: http_parser? Is anyone using something<br class="gmail_msg">
> else?<br class="gmail_msg">
> All that seems kinda covered/standard already? Unless maybe you include non-Unix stuff like Windows.<br class="gmail_msg">
><br class="gmail_msg">
> Is this primarily for things like providing a standardised ’swiftier' OpenSSL wrapper (similar to how Objective-GCD wraps libdispatch)?<br class="gmail_msg">
> Or would that just be module maps which are shipped by default with Swift and hence can be relied on by all frameworks?<br class="gmail_msg">
><br class="gmail_msg">
> But maybe I’m just a little too impatient :-><br class="gmail_msg">
><br class="gmail_msg">
> hh<br class="gmail_msg">
><br class="gmail_msg">
>> On 25 Oct 2016, at 20:41, Chris Bailey via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>> wrote:<br class="gmail_msg">
>><br class="gmail_msg">
>> Hi Ron:<br class="gmail_msg">
>><br class="gmail_msg">
>> 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.<br class="gmail_msg">
>><br class="gmail_msg">
>> 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.<br class="gmail_msg">
>><br class="gmail_msg">
>> Chris<br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>> From: Ron Olson via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>><br class="gmail_msg">
>> To: <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
>> Date: 25/10/2016 18:54<br class="gmail_msg">
>> Subject: [swift-server-dev] Database API/Framework<br class="gmail_msg">
>> Sent by: <a href="mailto:swift-server-dev-bounces@swift.org" class="gmail_msg" target="_blank">swift-server-dev-bounces@swift.org</a><br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>> Hi all-<br class="gmail_msg">
>><br class="gmail_msg">
>> I've been working with Swift more on Linux than macOS and am very<br class="gmail_msg">
>> excited to see the formation of this group. Looking at the server api<br class="gmail_msg">
>> workgroup's focus, I notice it's primarily low-level interaction with<br class="gmail_msg">
>> the operating system. When might it be a good time to bring up the<br class="gmail_msg">
>> possibility of creating a database-specific framework for those folks<br class="gmail_msg">
>> who want to work directly with Postgres, MySQL, even DB2 and Oracle; I'm<br class="gmail_msg">
>> thinking a JDBC-inspired framework that drivers could be written<br class="gmail_msg">
>> against.<br class="gmail_msg">
>><br class="gmail_msg">
>> Thanks,<br class="gmail_msg">
>><br class="gmail_msg">
>> Ron<br class="gmail_msg">
>> _______________________________________________<br class="gmail_msg">
>> swift-server-dev mailing list<br class="gmail_msg">
>> <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
>> <a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-server-dev</a><br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>> _______________________________________________<br class="gmail_msg">
>> swift-server-dev mailing list<br class="gmail_msg">
>> <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
>> <a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-server-dev</a><br class="gmail_msg">
><br class="gmail_msg">
> _______________________________________________<br class="gmail_msg">
> swift-server-dev mailing list<br class="gmail_msg">
> <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
> <a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-server-dev</a><br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
------------------------------<br class="gmail_msg">
<br class="gmail_msg">
Message: 7<br class="gmail_msg">
Date: Tue, 25 Oct 2016 15:34:24 -0400<br class="gmail_msg">
From: Haris Amin <<a href="mailto:aminharis7@gmail.com" class="gmail_msg" target="_blank">aminharis7@gmail.com</a>><br class="gmail_msg">
To: Paulo Faria <<a href="mailto:paulo@zewo.io" class="gmail_msg" target="_blank">paulo@zewo.io</a>>, Helge Heß <<a href="mailto:me@helgehess.eu" class="gmail_msg" target="_blank">me@helgehess.eu</a>>, Paulo<br class="gmail_msg">
Faria via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>><br class="gmail_msg">
Subject: Re: [swift-server-dev] Database API/Framework<br class="gmail_msg">
Message-ID:<br class="gmail_msg">
<CAG=aSgQ_byEvJPCcqU=<a href="mailto:kT6LRuT3xXYzk%2BLaabja2uYnVAaZDHg@mail.gmail.com" class="gmail_msg" target="_blank">kT6LRuT3xXYzk+Laabja2uYnVAaZDHg@mail.gmail.com</a>><br class="gmail_msg">
Content-Type: text/plain; charset="utf-8"<br class="gmail_msg">
<br class="gmail_msg">
Hey everyone,<br class="gmail_msg">
<br class="gmail_msg">
So I’m currently working on a pure Swift Postgres driver. It has no<br class="gmail_msg">
dependency on libpq at all. I’m parsing the Postgres Wire Protocol (V3)<br class="gmail_msg">
myself and everything seems great. Here are some problems/issues I’m facing<br class="gmail_msg">
that db driver implementers like myself (don’t shoot me this is my first<br class="gmail_msg">
shot at a db driver ;) ) would like to see resolved by this swift server<br class="gmail_msg">
group or we could use some guidance on:<br class="gmail_msg">
<br class="gmail_msg">
1. A standard socket api, there are a few right now. Currently I’m using<br class="gmail_msg">
IBM’s BlueSocket but really we just need one socket api that works cross<br class="gmail_msg">
platform. From the blog post it seems like that falls under this groups<br class="gmail_msg">
umbrella/objectives<br class="gmail_msg">
<br class="gmail_msg">
2. A lil more guidance around timestamps + time zones. These are super<br class="gmail_msg">
important for decent compliant swift db drivers. Can we rely on Foundation<br class="gmail_msg">
NSDate and timezones to work well cross platform without issues here?<br class="gmail_msg">
<br class="gmail_msg">
3. A standard lightweight crypto library to handle authentication. This is<br class="gmail_msg">
something all database driver authors will have to deal with (MD5 hashing<br class="gmail_msg">
etc). During the summer I had been switching between a few libraries but<br class="gmail_msg">
would be great to have this unified, cross platform support for this. Again<br class="gmail_msg">
I think this falls under the umbrella of this organization.<br class="gmail_msg">
<br class="gmail_msg">
4. Coming from a diverse backend/server background, I’ve seen different<br class="gmail_msg">
lang+environments handle sql interfaces differently. Most have left it up<br class="gmail_msg">
to third party frameworks/ecosystems (ruby/node/python) but some like<br class="gmail_msg">
Golang provide at least a default SQL interface that driver authors can<br class="gmail_msg">
adapt to. I’m starting to lean towards the latter of the two but I’m by no<br class="gmail_msg">
means and expert on anything :). This probably needs more community<br class="gmail_msg">
engagement/proposal.<br class="gmail_msg">
<br class="gmail_msg">
In short, for me at least, these 4 points would be great to be addressed<br class="gmail_msg">
(the 4th one perhaps is debatable and not as urgent), for database driver<br class="gmail_msg">
authors would greatly help a lot. Pretty much every server side swift<br class="gmail_msg">
framework right now has their own ORM-ish libs/frameworks. That’s awesome!<br class="gmail_msg">
My hope is we can start writing some of the drivers in pure Swift and help<br class="gmail_msg">
all those frameworks/libs get better too.<br class="gmail_msg">
<br class="gmail_msg">
Just my 2 cents. Perhaps this deserves a thread of its own. Perhaps it<br class="gmail_msg">
doesn’t. I apologize in advance if this is distracting from the current<br class="gmail_msg">
thread :)<br class="gmail_msg">
<br class="gmail_msg">
--<br class="gmail_msg">
Haris Amin<br class="gmail_msg">
Sent with Airmail<br class="gmail_msg">
<br class="gmail_msg">
On October 25, 2016 at 3:21:07 PM, Paulo Faria via swift-server-dev (<br class="gmail_msg">
<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>) wrote:<br class="gmail_msg">
<br class="gmail_msg">
Hello, Helge.<br class="gmail_msg">
<br class="gmail_msg">
Yes, most of the things we’ll cover are already provided by some<br class="gmail_msg">
frameworks, but having an official library joining efforts will be great<br class="gmail_msg">
for the community. We’ll provide full-fledged Swift libraries for the<br class="gmail_msg">
topics mentioned. How they’re going to be developed it’s still to be<br class="gmail_msg">
decided.<br class="gmail_msg">
<br class="gmail_msg">
Cheers,<br class="gmail_msg">
Paulo<br class="gmail_msg">
<br class="gmail_msg">
> On Oct 25, 2016, at 4:56 PM, Helge Heß via swift-server-dev <<br class="gmail_msg">
<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
> Hi Chris,<br class="gmail_msg">
><br class="gmail_msg">
> it is a little unclear what the scope of the group is. Presumably you<br class="gmail_msg">
have some very specific things in mind?<br class="gmail_msg">
><br class="gmail_msg">
> Of course we’ve seen <a href="https://swift.org/server-apis/#focus-areas" rel="noreferrer" class="gmail_msg" target="_blank">https://swift.org/server-apis/#focus-areas</a>. But what<br class="gmail_msg">
does it actually mean? :-) Looking at it:<br class="gmail_msg">
> - base networking: TCP/UDP, DNS. Covered already by libdispatch and the<br class="gmail_msg">
OS’ses?<br class="gmail_msg">
> - security: OpenSSL? or some wrapper around both, CC and OpenSSL?<br class="gmail_msg">
> - provide low level HTTP parsing: http_parser? Is anyone using something<br class="gmail_msg">
> else?<br class="gmail_msg">
> All that seems kinda covered/standard already? Unless maybe you include<br class="gmail_msg">
non-Unix stuff like Windows.<br class="gmail_msg">
><br class="gmail_msg">
> Is this primarily for things like providing a standardised ’swiftier'<br class="gmail_msg">
OpenSSL wrapper (similar to how Objective-GCD wraps libdispatch)?<br class="gmail_msg">
> Or would that just be module maps which are shipped by default with Swift<br class="gmail_msg">
and hence can be relied on by all frameworks?<br class="gmail_msg">
><br class="gmail_msg">
> But maybe I’m just a little too impatient :-><br class="gmail_msg">
><br class="gmail_msg">
> hh<br class="gmail_msg">
><br class="gmail_msg">
>> On 25 Oct 2016, at 20:41, Chris Bailey via swift-server-dev <<br class="gmail_msg">
<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>> wrote:<br class="gmail_msg">
>><br class="gmail_msg">
>> Hi Ron:<br class="gmail_msg">
>><br class="gmail_msg">
>> As you say, that's outside of the scope of the work group, however I do<br class="gmail_msg">
think its a valuable area that the various existing web framework groups<br class="gmail_msg">
might be interested in collaborating on. Having a common, recognized<br class="gmail_msg">
framework that the database providers or third parties would be interested<br class="gmail_msg">
in writing database drivers for would be a huge step forward.<br class="gmail_msg">
>><br class="gmail_msg">
>> I know that Vapor has its Fluent ORM framework, and that its an area<br class="gmail_msg">
that the Kitura team are looking at as well, so your post might kick-start<br class="gmail_msg">
some wider discussion.<br class="gmail_msg">
>><br class="gmail_msg">
>> Chris<br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>> From: Ron Olson via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>><br class="gmail_msg">
>> To: <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
>> Date: 25/10/2016 18:54<br class="gmail_msg">
>> Subject: [swift-server-dev] Database API/Framework<br class="gmail_msg">
>> Sent by: <a href="mailto:swift-server-dev-bounces@swift.org" class="gmail_msg" target="_blank">swift-server-dev-bounces@swift.org</a><br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>> Hi all-<br class="gmail_msg">
>><br class="gmail_msg">
>> I've been working with Swift more on Linux than macOS and am very<br class="gmail_msg">
>> excited to see the formation of this group. Looking at the server api<br class="gmail_msg">
>> workgroup's focus, I notice it's primarily low-level interaction with<br class="gmail_msg">
>> the operating system. When might it be a good time to bring up the<br class="gmail_msg">
>> possibility of creating a database-specific framework for those folks<br class="gmail_msg">
>> who want to work directly with Postgres, MySQL, even DB2 and Oracle; I'm<br class="gmail_msg">
>> thinking a JDBC-inspired framework that drivers could be written<br class="gmail_msg">
>> against.<br class="gmail_msg">
>><br class="gmail_msg">
>> Thanks,<br class="gmail_msg">
>><br class="gmail_msg">
>> Ron<br class="gmail_msg">
>> _______________________________________________<br class="gmail_msg">
>> swift-server-dev mailing list<br class="gmail_msg">
>> <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
>> <a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-server-dev</a><br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>> _______________________________________________<br class="gmail_msg">
>> swift-server-dev mailing list<br class="gmail_msg">
>> <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
>> <a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-server-dev</a><br class="gmail_msg">
><br class="gmail_msg">
> _______________________________________________<br class="gmail_msg">
> swift-server-dev mailing list<br class="gmail_msg">
> <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
> <a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-server-dev</a><br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
swift-server-dev mailing list<br class="gmail_msg">
<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-server-dev</a><br class="gmail_msg">
-------------- next part --------------<br class="gmail_msg">
An HTML attachment was scrubbed...<br class="gmail_msg">
URL: <<a href="https://lists.swift.org/pipermail/swift-server-dev/attachments/20161025/12d9cfc6/attachment-0001.html" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/pipermail/swift-server-dev/attachments/20161025/12d9cfc6/attachment-0001.html</a>><br class="gmail_msg">
<br class="gmail_msg">
------------------------------<br class="gmail_msg">
<br class="gmail_msg">
Message: 8<br class="gmail_msg">
Date: Tue, 25 Oct 2016 22:44:03 +0200<br class="gmail_msg">
From: Helge Heß <<a href="mailto:me@helgehess.eu" class="gmail_msg" target="_blank">me@helgehess.eu</a>><br class="gmail_msg">
To: Paulo Faria via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>><br class="gmail_msg">
Subject: Re: [swift-server-dev] Database API/Framework<br class="gmail_msg">
Message-ID: <<a href="mailto:96EBE4B7-013D-42E9-BDC4-715BB6ABD1F6@helgehess.eu" class="gmail_msg" target="_blank">96EBE4B7-013D-42E9-BDC4-715BB6ABD1F6@helgehess.eu</a>><br class="gmail_msg">
Content-Type: text/plain; charset=utf-8<br class="gmail_msg">
<br class="gmail_msg">
Hi,<br class="gmail_msg">
<br class="gmail_msg">
On 25 Oct 2016, at 21:34, Haris Amin <<a href="mailto:aminharis7@gmail.com" class="gmail_msg" target="_blank">aminharis7@gmail.com</a>> wrote:<br class="gmail_msg">
> So I’m currently working on a pure Swift Postgres driver.<br class="gmail_msg">
<br class="gmail_msg">
nice, I’m working on one as well (currently can run only basic queries, nothing fancy).<br class="gmail_msg">
<br class="gmail_msg">
> 1. A standard socket api, there are a few right now. Currently I’m using IBM’s BlueSocket but really we just need one socket api that works cross platform.<br class="gmail_msg">
<br class="gmail_msg">
I would be interested what people are really missing here (at that basic level). GCD channels are really quite nice for that kind of stuff (scheduling IO) and are already part of Swift 3. (I personally wonder how they scale compared to something like libuv, but for now I assume they do ;-)<br class="gmail_msg">
<br class="gmail_msg">
For making the Unix calls a little nicer Swift extensions on the Unix types are IMO pretty awesome, something along those lines:<br class="gmail_msg">
<br class="gmail_msg">
<a href="https://github.com/NozeIO/Noze.io/blob/master/Sources/net/SocketAddress.swift" rel="noreferrer" class="gmail_msg" target="_blank">https://github.com/NozeIO/Noze.io/blob/master/Sources/net/SocketAddress.swift</a><br class="gmail_msg">
<br class="gmail_msg">
I would avoid creating wrappers which are then just wrapped again by the higher level frameworks …<br class="gmail_msg">
<br class="gmail_msg">
The only real thing I’m missing is SSL support. But that already depends quite a lot on how the higher level frameworks deal with streams in general.<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
> 2. A lil more guidance around timestamps + time zones. These are super important for decent compliant swift db drivers. Can we rely on Foundation NSDate and timezones to work well cross platform without issues here?<br class="gmail_msg">
<br class="gmail_msg">
If it is part of Foundation you can assume it is supposed to work, right? :-)<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
> 3. A standard lightweight crypto library to handle authentication. This is something all database driver authors will have to deal with (MD5 hashing etc). During the summer I had been switching between a few libraries but would be great to have this unified, cross platform support for this. Again I think this falls under the umbrella of this organization.<br class="gmail_msg">
<br class="gmail_msg">
+1 (And that should probably be part of Foundation as it is required just the same on the client side).<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
> 4. Coming from a diverse backend/server background, I’ve seen different lang+environments handle sql interfaces differently. Most have left it up to third party frameworks/ecosystems (ruby/node/python) but some like Golang provide at least a default SQL interface that driver authors can adapt to. I’m starting to lean towards the latter of the two but I’m by no means and expert on anything :). This probably needs more community engagement/proposal.<br class="gmail_msg">
<br class="gmail_msg">
IMHO that sounds more like something the higher level frameworks (ORMs) should be concerned about (as they will define what they want to map from and how, and probably in pretty different ways). But maybe not. Personally I’d like to avoid something like JDBC as it provides little value at extra overhead.<br class="gmail_msg">
<br class="gmail_msg">
As an example: if I have received a DispatchData from the socket containing a PG row values, I don’t want to first convert that to a JDBC or EOAdaptor record-Dictionary<Key,Any>> which is then mapped to a Customer.purchaseStatus enum. I would rather like to pass up that DispatchData to the highest level and only have it converted at the very last point and only if necessary - sometimes an ORM, but other times it may be just directly streamed into a different format, say JSON (in such cases you can often accomplish zero-copy).<br class="gmail_msg">
<br class="gmail_msg">
> My hope is we can start writing some of the drivers in pure Swift and help all those frameworks/libs get better too.<br class="gmail_msg">
<br class="gmail_msg">
Not sure a generic ‘driver' interface will help a lot here. I think you help most by providing a SwiftPQ library which can then be integrated by the ORMs/frameworks in a way which fits best.<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
Anywayz, interesting to see what people come up with :-)<br class="gmail_msg">
<br class="gmail_msg">
hh<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
------------------------------<br class="gmail_msg">
<br class="gmail_msg">
Message: 9<br class="gmail_msg">
Date: Tue, 25 Oct 2016 15:55:23 -0500<br class="gmail_msg">
From: "Ron Olson" <<a href="mailto:tachoknight@gmail.com" class="gmail_msg" target="_blank">tachoknight@gmail.com</a>><br class="gmail_msg">
To: <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
Subject: Re: [swift-server-dev] Database API/Framework<br class="gmail_msg">
Message-ID: <<a href="mailto:BA9D7BA9-3E1A-47C3-81E8-8DE02817B74D@gmail.com" class="gmail_msg" target="_blank">BA9D7BA9-3E1A-47C3-81E8-8DE02817B74D@gmail.com</a>><br class="gmail_msg">
Content-Type: text/plain; charset=utf-8; format=flowed<br class="gmail_msg">
<br class="gmail_msg">
I mentioned JDBC because I happened to be looking at some Java code at<br class="gmail_msg">
the time, but I really meant 'generic-interface' to provide the<br class="gmail_msg">
lowest-level-but-no-lower-than-necessary access to the database,<br class="gmail_msg">
regardless of whether it was sqlite or postgres. I think Go does a<br class="gmail_msg">
pretty good job of providing that thin layer of abstraction and it's up<br class="gmail_msg">
the driver writer to implement. After that what somebody wants to do<br class="gmail_msg">
with the results is their business.<br class="gmail_msg">
<br class="gmail_msg">
Personally I don't like ORM layers; most of the time I'm writing complex<br class="gmail_msg">
queries that don't fit neatly into an ORM paradigm and I end up fighting<br class="gmail_msg">
with the framework.<br class="gmail_msg">
<br class="gmail_msg">
Ron<br class="gmail_msg">
<br class="gmail_msg">
On 25 Oct 2016, at 15:44, Helge Heß via swift-server-dev wrote:<br class="gmail_msg">
<br class="gmail_msg">
> Hi,<br class="gmail_msg">
><br class="gmail_msg">
> On 25 Oct 2016, at 21:34, Haris Amin <<a href="mailto:aminharis7@gmail.com" class="gmail_msg" target="_blank">aminharis7@gmail.com</a>> wrote:<br class="gmail_msg">
>> So I’m currently working on a pure Swift Postgres driver.<br class="gmail_msg">
><br class="gmail_msg">
> nice, I’m working on one as well (currently can run only basic<br class="gmail_msg">
> queries, nothing fancy).<br class="gmail_msg">
><br class="gmail_msg">
>> 1. A standard socket api, there are a few right now. Currently I’m<br class="gmail_msg">
>> using IBM’s BlueSocket but really we just need one socket api that<br class="gmail_msg">
>> works cross platform.<br class="gmail_msg">
><br class="gmail_msg">
> I would be interested what people are really missing here (at that<br class="gmail_msg">
> basic level). GCD channels are really quite nice for that kind of<br class="gmail_msg">
> stuff (scheduling IO) and are already part of Swift 3. (I personally<br class="gmail_msg">
> wonder how they scale compared to something like libuv, but for now I<br class="gmail_msg">
> assume they do ;-)<br class="gmail_msg">
><br class="gmail_msg">
> For making the Unix calls a little nicer Swift extensions on the Unix<br class="gmail_msg">
> types are IMO pretty awesome, something along those lines:<br class="gmail_msg">
><br class="gmail_msg">
> <a href="https://github.com/NozeIO/Noze.io/blob/master/Sources/net/SocketAddress.swift" rel="noreferrer" class="gmail_msg" target="_blank">https://github.com/NozeIO/Noze.io/blob/master/Sources/net/SocketAddress.swift</a><br class="gmail_msg">
><br class="gmail_msg">
> I would avoid creating wrappers which are then just wrapped again by<br class="gmail_msg">
> the higher level frameworks …<br class="gmail_msg">
><br class="gmail_msg">
> The only real thing I’m missing is SSL support. But that already<br class="gmail_msg">
> depends quite a lot on how the higher level frameworks deal with<br class="gmail_msg">
> streams in general.<br class="gmail_msg">
><br class="gmail_msg">
>> 2. A lil more guidance around timestamps + time zones. These are<br class="gmail_msg">
>> super important for decent compliant swift db drivers. Can we rely on<br class="gmail_msg">
>> Foundation NSDate and timezones to work well cross platform without<br class="gmail_msg">
>> issues here?<br class="gmail_msg">
><br class="gmail_msg">
> If it is part of Foundation you can assume it is supposed to work,<br class="gmail_msg">
> right? :-)<br class="gmail_msg">
><br class="gmail_msg">
>> 3. A standard lightweight crypto library to handle authentication.<br class="gmail_msg">
>> This is something all database driver authors will have to deal with<br class="gmail_msg">
>> (MD5 hashing etc). During the summer I had been switching between a<br class="gmail_msg">
>> few libraries but would be great to have this unified, cross platform<br class="gmail_msg">
>> support for this. Again I think this falls under the umbrella of this<br class="gmail_msg">
>> organization.<br class="gmail_msg">
><br class="gmail_msg">
> +1 (And that should probably be part of Foundation as it is required<br class="gmail_msg">
> just the same on the client side).<br class="gmail_msg">
><br class="gmail_msg">
>> 4. Coming from a diverse backend/server background, I’ve seen<br class="gmail_msg">
>> different lang+environments handle sql interfaces differently. Most<br class="gmail_msg">
>> have left it up to third party frameworks/ecosystems<br class="gmail_msg">
>> (ruby/node/python) but some like Golang provide at least a default<br class="gmail_msg">
>> SQL interface that driver authors can adapt to. I’m starting to<br class="gmail_msg">
>> lean towards the latter of the two but I’m by no means and expert<br class="gmail_msg">
>> on anything :). This probably needs more community<br class="gmail_msg">
>> engagement/proposal.<br class="gmail_msg">
><br class="gmail_msg">
> IMHO that sounds more like something the higher level frameworks<br class="gmail_msg">
> (ORMs) should be concerned about (as they will define what they want<br class="gmail_msg">
> to map from and how, and probably in pretty different ways). But maybe<br class="gmail_msg">
> not. Personally I’d like to avoid something like JDBC as it provides<br class="gmail_msg">
> little value at extra overhead.<br class="gmail_msg">
><br class="gmail_msg">
> As an example: if I have received a DispatchData from the socket<br class="gmail_msg">
> containing a PG row values, I don’t want to first convert that to a<br class="gmail_msg">
> JDBC or EOAdaptor record-Dictionary<Key,Any>> which is then mapped to<br class="gmail_msg">
> a Customer.purchaseStatus enum. I would rather like to pass up that<br class="gmail_msg">
> DispatchData to the highest level and only have it converted at the<br class="gmail_msg">
> very last point and only if necessary - sometimes an ORM, but other<br class="gmail_msg">
> times it may be just directly streamed into a different format, say<br class="gmail_msg">
> JSON (in such cases you can often accomplish zero-copy).<br class="gmail_msg">
><br class="gmail_msg">
>> My hope is we can start writing some of the drivers in pure Swift and<br class="gmail_msg">
>> help all those frameworks/libs get better too.<br class="gmail_msg">
><br class="gmail_msg">
> Not sure a generic ‘driver' interface will help a lot here. I think<br class="gmail_msg">
> you help most by providing a SwiftPQ library which can then be<br class="gmail_msg">
> integrated by the ORMs/frameworks in a way which fits best.<br class="gmail_msg">
><br class="gmail_msg">
> Anywayz, interesting to see what people come up with :-)<br class="gmail_msg">
><br class="gmail_msg">
> hh<br class="gmail_msg">
><br class="gmail_msg">
> _______________________________________________<br class="gmail_msg">
> swift-server-dev mailing list<br class="gmail_msg">
> <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
> <a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-server-dev</a><br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
------------------------------<br class="gmail_msg">
<br class="gmail_msg">
Message: 10<br class="gmail_msg">
Date: Wed, 26 Oct 2016 00:00:35 +0200<br class="gmail_msg">
From: Alex Blewitt <<a href="mailto:alblue@apple.com" class="gmail_msg" target="_blank">alblue@apple.com</a>><br class="gmail_msg">
To: <a href="mailto:frogcjn@163.com" class="gmail_msg" target="_blank">frogcjn@163.com</a><br class="gmail_msg">
Cc: swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>><br class="gmail_msg">
Subject: Re: [swift-server-dev] [Bug] Foundation.URL should support<br class="gmail_msg">
semicolon(; ) appearing in URL path<br class="gmail_msg">
Message-ID: <<a href="mailto:3A980DA0-E213-4DBE-B928-C36094446C00@apple.com" class="gmail_msg" target="_blank">3A980DA0-E213-4DBE-B928-C36094446C00@apple.com</a>><br class="gmail_msg">
Content-Type: text/plain; charset=utf-8<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
> On 25 Oct 2016, at 21:09, Cao, Jiannan via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> <a href="http://host/book;id=1/page;2/" rel="noreferrer" class="gmail_msg" target="_blank">http://host/book;id=1/page;2/</a><br class="gmail_msg">
><br class="gmail_msg">
> this URL is a valid URL, but URLComponents will ruin it with %3B<br class="gmail_msg">
> <a href="http://host/book%3Bid=1/page%3B2/" rel="noreferrer" class="gmail_msg" target="_blank">http://host/book%3Bid=1/page%3B2/</a><br class="gmail_msg">
><br class="gmail_msg">
> Since Swift Server is coming out, this bug should be solved.<br class="gmail_msg">
<br class="gmail_msg">
Can you report this on <a href="https://bugs.swift.org" rel="noreferrer" class="gmail_msg" target="_blank">https://bugs.swift.org</a> so that it's tracked appropriately?<br class="gmail_msg">
<br class="gmail_msg">
Thanks,<br class="gmail_msg">
<br class="gmail_msg">
Alex<br class="gmail_msg">
<br class="gmail_msg">
Sent from my iPhone 📱<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
------------------------------<br class="gmail_msg">
<br class="gmail_msg">
Message: 11<br class="gmail_msg">
Date: Tue, 25 Oct 2016 16:11:55 -0700<br class="gmail_msg">
From: Rick Mann <<a href="mailto:rmann@latencyzero.com" class="gmail_msg" target="_blank">rmann@latencyzero.com</a>><br class="gmail_msg">
To: <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
Subject: [swift-server-dev] Spring and Baratine (Java frameworks)<br class="gmail_msg">
Message-ID: <<a href="mailto:1736F138-7246-460C-9CC2-781446A1C90F@latencyzero.com" class="gmail_msg" target="_blank">1736F138-7246-460C-9CC2-781446A1C90F@latencyzero.com</a>><br class="gmail_msg">
Content-Type: text/plain; charset=us-ascii<br class="gmail_msg">
<br class="gmail_msg">
Hi all,<br class="gmail_msg">
<br class="gmail_msg">
I'm very excited for the formation of this area of development. While I might consider myself primarily a macOS and iOS app developer, I've done my fair share of Java webserver development, as well as a lot of small embedded development. You can't make a non-trivial app these days without some kind of server-side support.<br class="gmail_msg">
<br class="gmail_msg">
I realize the initial focus of this working group is fairly low-level support for server-side development, but in much the same way that Swift development is made richer by the availability of the robust Swift Standard Library, so to is web development.<br class="gmail_msg">
<br class="gmail_msg">
In my estimation, the most current iterations of Spring.io, and the up-and-coming Baratine.io*, offer insights into powerful web development paradigms that I'd like to see streamlined and Swiftified. While this group is avoiding such a high-level, it strikes me that thinking about the high level can greatly inform how the low-level APIs evolve.<br class="gmail_msg">
<br class="gmail_msg">
One of the things that Java frameworks take advantage of is Java's rich introspective ability, and particularly lately use @Annotations as a way to simplify configuration and reduce boilerplate code. This typically expands into dynamic creation of proxy classes, and I'm not sure how Swift's introspection and code-generation capabilities stack up. I know Java-style @Annotations are on the roadmap in some form, but not until after ABI stability.<br class="gmail_msg">
<br class="gmail_msg">
Unfortunately, I think that means any Swift webapp framework will suffer problems similar to that of Spring: a clunky datafile-based configuration structure that becomes obsolete when more introspection features become available, creating a wealth of out-of-date instructional material online and a lot of technical debt.<br class="gmail_msg">
<br class="gmail_msg">
Hopefully I'm being overly pessimistic, and we're able to enjoy elegant, powerful, scalable web development in the near future.<br class="gmail_msg">
<br class="gmail_msg">
In any case, I hope I can make a positive contribution.<br class="gmail_msg">
<br class="gmail_msg">
--<br class="gmail_msg">
Rick Mann<br class="gmail_msg">
<a href="mailto:rmann@latencyzero.com" class="gmail_msg" target="_blank">rmann@latencyzero.com</a><br class="gmail_msg">
<br class="gmail_msg">
*Baratine is incredibly performant and substantially relieves the developer from the persistence burden, but IMHO currently is quite verbose when it comes to implementing something like REST endpoints, and has a very steep learning (grokking?) curve.<br class="gmail_msg">
<br class="gmail_msg">
------------------------------<br class="gmail_msg">
<br class="gmail_msg">
Message: 12<br class="gmail_msg">
Date: Tue, 25 Oct 2016 17:30:31 -0700<br class="gmail_msg">
From: Tyler Cloutier <<a href="mailto:cloutiertyler@aol.com" class="gmail_msg" target="_blank">cloutiertyler@aol.com</a>><br class="gmail_msg">
To: <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
Subject: [swift-server-dev] Lib dispatch and Edge<br class="gmail_msg">
Message-ID: <<a href="mailto:56052D8D-8D9D-43E9-B9BF-0A77A09B04D2@aol.com" class="gmail_msg" target="_blank">56052D8D-8D9D-43E9-B9BF-0A77A09B04D2@aol.com</a>><br class="gmail_msg">
Content-Type: text/plain; charset=utf-8<br class="gmail_msg">
<br class="gmail_msg">
Hello everyone!<br class="gmail_msg">
<br class="gmail_msg">
I just wanted to say that I look forward to contributing to this group! I have been working on server side Swift for a while and I’ve created the project, Edge, on Github. <a href="https://github.com/SwiftOnEdge/Edge" rel="noreferrer" class="gmail_msg" target="_blank">https://github.com/SwiftOnEdge/Edge</a><br class="gmail_msg">
<br class="gmail_msg">
It uses the libdispatch (Dispatch) api to create a nodejs like asynchronous server APIs. I would love to be able to contribute some of my work to the Server APIs project.<br class="gmail_msg">
<br class="gmail_msg">
Thank you,<br class="gmail_msg">
<br class="gmail_msg">
Tyler<br class="gmail_msg">
<br class="gmail_msg">
------------------------------<br class="gmail_msg">
<br class="gmail_msg">
Message: 13<br class="gmail_msg">
Date: Wed, 26 Oct 2016 10:00:59 +0100<br class="gmail_msg">
From: Yoann Gini <<a href="mailto:yoann.gini@gmail.com" class="gmail_msg" target="_blank">yoann.gini@gmail.com</a>><br class="gmail_msg">
To: <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
Subject: [swift-server-dev] Why not rely on existing models?<br class="gmail_msg">
Message-ID: <<a href="mailto:E3E74862-0681-43F3-B526-B75DD3BE497F@gmail.com" class="gmail_msg" target="_blank">E3E74862-0681-43F3-B526-B75DD3BE497F@gmail.com</a>><br class="gmail_msg">
Content-Type: text/plain; charset="utf-8"<br class="gmail_msg">
<br class="gmail_msg">
Hi<br class="gmail_msg">
<br class="gmail_msg">
I’m following Swift server side initiatives really closely. I’m a developer and sys admin, really interested in subjects linked to performance and security.<br class="gmail_msg">
<br class="gmail_msg">
Swift look like a perfect language for server side, especially with Cocoa framework on the back.<br class="gmail_msg">
<br class="gmail_msg">
Looking at all the current initiative, I’ve to say don’t understand something: why everyone start by creating a brand new HTTP server?<br class="gmail_msg">
<br class="gmail_msg">
>From a DevOps point of view, it looks like a waste of resources to start writing HTTP server framework in swift. No sys admin will ever allow a small custom HTTP server to be open to the Internet without a proxy before. Plus, we already have two really great HTTP servers in the UNIX world, Apache and NGINX. In no way a custom HTTP language related framework can cover as much as those two projects.<br class="gmail_msg">
<br class="gmail_msg">
Even if I understand some people might want built-in HTTP handler in a client/server app, I don’t really understand why all existing initiatives take this road.<br class="gmail_msg">
<br class="gmail_msg">
Looking at what currently exists, I found WSGI (or even old school CGI) way more interesting for production purpose.<br class="gmail_msg">
<br class="gmail_msg">
If we are trying to deploy Swift on the server side, CGI alike solution look like the quick win. It avoid wasting dev time by reusing all HTTP server already existing, so developer from this community will have to concentrate only to create a bridge. And even more, this bridge can be created in the first version by simply porting WSGI behavior to Swift.<br class="gmail_msg">
<br class="gmail_msg">
This is just a simple personal opinion. Just wondering why.<br class="gmail_msg">
<br class="gmail_msg">
Best regards,<br class="gmail_msg">
Yoann Gini<br class="gmail_msg">
<br class="gmail_msg">
-------------- next part --------------<br class="gmail_msg">
An HTML attachment was scrubbed...<br class="gmail_msg">
URL: <<a href="https://lists.swift.org/pipermail/swift-server-dev/attachments/20161026/8124b46d/attachment-0001.html" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/pipermail/swift-server-dev/attachments/20161026/8124b46d/attachment-0001.html</a>><br class="gmail_msg">
<br class="gmail_msg">
------------------------------<br class="gmail_msg">
<br class="gmail_msg">
Message: 14<br class="gmail_msg">
Date: Wed, 26 Oct 2016 11:25:16 +0200<br class="gmail_msg">
From: Helge Heß <<a href="mailto:me@helgehess.eu" class="gmail_msg" target="_blank">me@helgehess.eu</a>><br class="gmail_msg">
To: Paulo Faria via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>><br class="gmail_msg">
Subject: Re: [swift-server-dev] Why not rely on existing models?<br class="gmail_msg">
Message-ID: <<a href="mailto:8296A4EE-B0C1-449D-8F64-3C50231CB0F9@helgehess.eu" class="gmail_msg" target="_blank">8296A4EE-B0C1-449D-8F64-3C50231CB0F9@helgehess.eu</a>><br class="gmail_msg">
Content-Type: text/plain; charset=us-ascii<br class="gmail_msg">
<br class="gmail_msg">
Is there a need for a swift-server-users mailing list?<br class="gmail_msg">
<br class="gmail_msg">
hh<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
------------------------------<br class="gmail_msg">
<br class="gmail_msg">
Message: 15<br class="gmail_msg">
Date: Wed, 26 Oct 2016 02:34:10 -0700<br class="gmail_msg">
From: Brent Royal-Gordon <<a href="mailto:brent@architechies.com" class="gmail_msg" target="_blank">brent@architechies.com</a>><br class="gmail_msg">
To: <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
Subject: [swift-server-dev] Re: Database API/Framework<br class="gmail_msg">
Message-ID: <<a href="mailto:1FED5955-F653-4D36-8C82-986695A01CBE@architechies.com" class="gmail_msg" target="_blank">1FED5955-F653-4D36-8C82-986695A01CBE@architechies.com</a>><br class="gmail_msg">
Content-Type: text/plain; charset=utf-8<br class="gmail_msg">
<br class="gmail_msg">
(Sorry for the fake threading; I read this thread in the web archive and wanted to chime in.)<br class="gmail_msg">
<br class="gmail_msg">
Helge Heß:<br class="gmail_msg">
<br class="gmail_msg">
> > 4. Coming from a diverse backend/server background, I’ve seen different lang+environments handle sql interfaces differently. Most have left it up to third party frameworks/ecosystems (ruby/node/python) but some like Golang provide at least a default SQL interface that driver authors can adapt to. I’m starting to lean towards the latter of the two but I’m by no means and expert on anything :). This probably needs more community engagement/proposal.<br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> IMHO that sounds more like something the higher level frameworks (ORMs) should be concerned about (as they will define what they want to map from and how, and probably in pretty different ways). But maybe not. Personally I’d like to avoid something like JDBC as it provides little value at extra overhead.<br class="gmail_msg">
><br class="gmail_msg">
> As an example: if I have received a DispatchData from the socket containing a PG row values, I don’t want to first convert that to a JDBC or EOAdaptor record-Dictionary<Key,Any>> which is then mapped to a Customer.purchaseStatus enum. I would rather like to pass up that DispatchData to the highest level and only have it converted at the very last point and only if necessary - sometimes an ORM, but other times it may be just directly streamed into a different format, say JSON (in such cases you can often accomplish zero-copy).<br class="gmail_msg">
><br class="gmail_msg">
> > My hope is we can start writing some of the drivers in pure Swift and help all those frameworks/libs get better too.<br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> Not sure a generic ‘driver' interface will help a lot here. I think you help most by providing a SwiftPQ library which can then be integrated by the ORMs/frameworks in a way which fits best.<br class="gmail_msg">
<br class="gmail_msg">
I think Perl has a good model we might want to pay attention to. Perl has a largely database-independent library called DBI (Database Interface) which basically just standardizes the interfaces to connect to databases, run queries, iterate through results, examine schemas, and so on. A system of plug-ins, called DBDs (Database Drivers), handle each individual database. Applications can either use DBI directly or through a library that functions as an ORM. (Most of these higher-level libraries are called DBI Extensions (DBIx), though this is just a convention.)<br class="gmail_msg">
<br class="gmail_msg">
Drivers Interface Extension/Client<br class="gmail_msg">
DBD::MySQL -+ +- DBIx::Class<br class="gmail_msg">
DBD::PG -+----- DBI ----- +- DBIx::DataModel<br class="gmail_msg">
DBD::Oracle -+ +- Direct use<br class="gmail_msg">
<br class="gmail_msg">
DBI doesn't abstract away *all* differences between databases. But it gets most of them, and in practice, it's not very difficult to switch from one database to another, or use different databases in development and production. It saves individual ORMs from needing to individually implement different database backends, and facilitates sharing of code for features like connection pooling. If the interest is there, this can support a wide and varied ecosystem: Perl's CPAN module repository includes 103 DBD modules and 473 DBIx modules.<br class="gmail_msg">
<br class="gmail_msg">
In Swift, we may also be able to use it to encourage good database practices. The control Swift offers over string literals and interpolation could be leveraged to encourage use of prepared statements and good escaping (or rather, use of parameterized queries instead of escaping). Imagine if, when you wrote something like this, it was perfectly safe:<br class="gmail_msg">
<br class="gmail_msg">
let userID = …<br class="gmail_msg">
for row in try connection.query("SELECT * FROM posts WHERE user_id = \(userID)") {<br class="gmail_msg">
// `query`'s parameter is actually a `SQLStatement`, so the string literal is actually a SQL statement literal.<br class="gmail_msg">
…<br class="gmail_msg">
}<br class="gmail_msg">
<br class="gmail_msg">
Because `userID` would be an `Int`—that is, a type expected to contain data—it would be automatically passed as a parameter so there were no escaping issues. If you used a type for a table, column, or fragment of a statement, on the other hand, it would be handled appropriately:<br class="gmail_msg">
<br class="gmail_msg">
let userID = …<br class="gmail_msg">
let sortColumnName = …<br class="gmail_msg">
let ascending = …<br class="gmail_msg">
<br class="gmail_msg">
let postsTable = try! SQLTable("posts", in: connection)<br class="gmail_msg">
let sortColumn = try SQLColumn(named: sortColumnName, in: postsTable)<br class="gmail_msg">
let sortDirection: SQLFragment = ascending ? "ASC" : "DESC"<br class="gmail_msg">
<br class="gmail_msg">
for row in try connection.query("SELECT * FROM \(postsTable) WHERE user_id = \(userID) ORDER BY \(sortColumn) \(sortDirection)") {<br class="gmail_msg">
// In the above, the SQLTable, SQLColumn, and SQLStatementFragment are inserted without escaping,<br class="gmail_msg">
// while the non-database-specific userID is passed as a parameter.<br class="gmail_msg">
…<br class="gmail_msg">
}<br class="gmail_msg">
<br class="gmail_msg">
This is cool stuff that the dynamic languages don't offer, but you probably don't want to write it for each individual database driver. You want to write it once, either at the database-independent interface layer or as a layer above it. To do that, you need to funnel all database use through a single chokepoint. In other words, you need something like DBI.<br class="gmail_msg">
<br class="gmail_msg">
I'm not saying we should adopt DBI exactly as it is—Swift would demand a very different design. But I think we should consider using a similar architecture. It has a lot of advantages over forcing high-level frameworks to talk directly to low-level databases.<br class="gmail_msg">
<br class="gmail_msg">
--<br class="gmail_msg">
Brent Royal-Gordon<br class="gmail_msg">
Architechies<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
------------------------------<br class="gmail_msg">
<br class="gmail_msg">
Message: 16<br class="gmail_msg">
Date: Wed, 26 Oct 2016 10:43:07 +0100<br class="gmail_msg">
From: Yoann Gini <<a href="mailto:yoann.gini@gmail.com" class="gmail_msg" target="_blank">yoann.gini@gmail.com</a>><br class="gmail_msg">
To: Helge Heß <<a href="mailto:me@helgehess.eu" class="gmail_msg" target="_blank">me@helgehess.eu</a>><br class="gmail_msg">
Cc: Paulo Faria via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>><br class="gmail_msg">
Subject: Re: [swift-server-dev] Why not rely on existing models?<br class="gmail_msg">
Message-ID: <<a href="mailto:D85F7505-334D-43D0-91BF-2183416636E2@gmail.com" class="gmail_msg" target="_blank">D85F7505-334D-43D0-91BF-2183416636E2@gmail.com</a>><br class="gmail_msg">
Content-Type: text/plain; charset=utf-8<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
> Le 26 oct. 2016 à 10:25, Helge Heß via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>> a écrit :<br class="gmail_msg">
><br class="gmail_msg">
> Is there a need for a swift-server-users mailing list?<br class="gmail_msg">
<br class="gmail_msg">
It depends on whether you consider a language is made for the language itself or for production. Considering real case usage scenarios and constraints might be a good idea in any kind of software development.<br class="gmail_msg">
<br class="gmail_msg">
In particular, advocating for WSGI alike integration isn’t a user consideration but a request for the server side app developers who would like to avoid coming back to the Stone Age of Tomcat.<br class="gmail_msg">
<br class="gmail_msg">
Best regards,<br class="gmail_msg">
Yoann Gini<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
------------------------------<br class="gmail_msg">
<br class="gmail_msg">
Message: 17<br class="gmail_msg">
Date: Wed, 26 Oct 2016 02:59:23 -0700<br class="gmail_msg">
From: Brent Royal-Gordon <<a href="mailto:brent@architechies.com" class="gmail_msg" target="_blank">brent@architechies.com</a>><br class="gmail_msg">
To: Yoann Gini <<a href="mailto:yoann.gini@gmail.com" class="gmail_msg" target="_blank">yoann.gini@gmail.com</a>><br class="gmail_msg">
Cc: <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
Subject: Re: [swift-server-dev] Why not rely on existing models?<br class="gmail_msg">
Message-ID: <<a href="mailto:ABF1424E-6E00-4E3D-B68A-82A590D74143@architechies.com" class="gmail_msg" target="_blank">ABF1424E-6E00-4E3D-B68A-82A590D74143@architechies.com</a>><br class="gmail_msg">
Content-Type: text/plain; charset=utf-8<br class="gmail_msg">
<br class="gmail_msg">
> On Oct 26, 2016, at 2:00 AM, Yoann Gini via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
> Looking at all the current initiative, I’ve to say don’t understand something: why everyone start by creating a brand new HTTP server?<br class="gmail_msg">
><br class="gmail_msg">
> From a DevOps point of view, it looks like a waste of resources to start writing HTTP server framework in swift. No sys admin will ever allow a small custom HTTP server to be open to the Internet without a proxy before. Plus, we already have two really great HTTP servers in the UNIX world, Apache and NGINX. In no way a custom HTTP language related framework can cover as much as those two projects.<br class="gmail_msg">
><br class="gmail_msg">
> Even if I understand some people might want built-in HTTP handler in a client/server app, I don’t really understand why all existing initiatives take this road.<br class="gmail_msg">
<br class="gmail_msg">
This trend seems to have started with Rails. It has a few advantages:<br class="gmail_msg">
<br class="gmail_msg">
1. You can use the embedded server in development and testing. This is *way* easier than installing Apache on your development machine or CI setup and configuring it to point to your application.<br class="gmail_msg">
<br class="gmail_msg">
2. In production, you can configure Apache or nginx to reverse proxy for the app; this configuration is almost entirely agnostic to the application itself, so you can modify the application's behavior without playing with the frontend web server.<br class="gmail_msg">
<br class="gmail_msg">
3. The frontend proxy and backend web server communicate over a plain old socket, so they can run as different user accounts or even in separate VMs.<br class="gmail_msg">
<br class="gmail_msg">
Basically, embedding a web server and reverse proxying for it isolates the application from the frontend server and simplifies the management of both.<br class="gmail_msg">
<br class="gmail_msg">
--<br class="gmail_msg">
Brent Royal-Gordon<br class="gmail_msg">
Architechies<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
------------------------------<br class="gmail_msg">
<br class="gmail_msg">
Message: 18<br class="gmail_msg">
Date: Wed, 26 Oct 2016 12:26:51 +0200<br class="gmail_msg">
From: Helge Heß <<a href="mailto:me@helgehess.eu" class="gmail_msg" target="_blank">me@helgehess.eu</a>><br class="gmail_msg">
To: Paulo Faria via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>><br class="gmail_msg">
Subject: Re: [swift-server-dev] Database API/Framework<br class="gmail_msg">
Message-ID: <<a href="mailto:D7AB25BE-3BAF-4C9B-A2C4-2B0A6243A93F@helgehess.eu" class="gmail_msg" target="_blank">D7AB25BE-3BAF-4C9B-A2C4-2B0A6243A93F@helgehess.eu</a>><br class="gmail_msg">
Content-Type: text/plain; charset=utf-8<br class="gmail_msg">
<br class="gmail_msg">
On 26 Oct 2016, at 11:34, Brent Royal-Gordon via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>> wrote:<br class="gmail_msg">
> I'm not saying we should adopt DBI exactly as it is—Swift would demand a very different design. But I think we should consider using a similar architecture. It has a lot of advantages over forcing high-level frameworks to talk directly to low-level databases.<br class="gmail_msg">
<br class="gmail_msg">
This is essentially the original message of the request, the desire to have a JDBC. Maybe people really want to have that :-) I guess a few protocols for simple use cases do not hurt, but I would advise against over designing this.<br class="gmail_msg">
<br class="gmail_msg">
IMHO it doesn’t make that much sense since todays databases are so different. If you are a PostgreSQL user, you quite likely want to make use of its features (be it JSON columns, FTS, custom types, row permissions, table inheritance, etc).<br class="gmail_msg">
Even pooling has very different requirements based on the setup of the database (e.g. in PG connections are pretty expensive, in others not at all, and SQLite doesn’t even have them). Let alone transactions and how they behave.<br class="gmail_msg">
Presumably a HL framework has to have specific support to account for dealing with such differences, it can’t just rely on ‘JDBC'.<br class="gmail_msg">
<br class="gmail_msg">
Personally I’m more interested in comprehensive interaction modules for the respective databases that can be used by all HL projects than in an API trying to bundle everything into a set of basic protocols. It is the HL project presenting a consistent API to the enduser (be it a full ORM or something more low level [e.g. I would rather stream batches of tuples coming from the database than building an EOF/CoreData like object graph]).<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
But I’m quite interested to see what proposals are coming in :-)<br class="gmail_msg">
<br class="gmail_msg">
hh<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
------------------------------<br class="gmail_msg">
<br class="gmail_msg">
Message: 19<br class="gmail_msg">
Date: Wed, 26 Oct 2016 11:33:43 +0100<br class="gmail_msg">
From: Yoann Gini <<a href="mailto:yoann.gini@gmail.com" class="gmail_msg" target="_blank">yoann.gini@gmail.com</a>><br class="gmail_msg">
To: Brent Royal-Gordon <<a href="mailto:brent@architechies.com" class="gmail_msg" target="_blank">brent@architechies.com</a>><br class="gmail_msg">
Cc: <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
Subject: Re: [swift-server-dev] Why not rely on existing models?<br class="gmail_msg">
Message-ID: <<a href="mailto:7D95AB95-528E-43AC-9594-4E4A2A603E6F@gmail.com" class="gmail_msg" target="_blank">7D95AB95-528E-43AC-9594-4E4A2A603E6F@gmail.com</a>><br class="gmail_msg">
Content-Type: text/plain; charset=utf-8<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
> Le 26 oct. 2016 à 10:59, Brent Royal-Gordon <<a href="mailto:brent@architechies.com" class="gmail_msg" target="_blank">brent@architechies.com</a>> a écrit :<br class="gmail_msg">
><br class="gmail_msg">
> This trend seems to have started with Rails. It has a few advantages:<br class="gmail_msg">
><br class="gmail_msg">
> 1. You can use the embedded server in development and testing. This is *way* easier than installing Apache on your development machine or CI setup and configuring it to point to your application.<br class="gmail_msg">
<br class="gmail_msg">
100% agree with that<br class="gmail_msg">
<br class="gmail_msg">
> 2. In production, you can configure Apache or nginx to reverse proxy for the app; this configuration is almost entirely agnostic to the application itself, so you can modify the application's behavior without playing with the frontend web server.<br class="gmail_msg">
><br class="gmail_msg">
> 3. The frontend proxy and backend web server communicate over a plain old socket, so they can run as different user accounts or even in separate VMs.<br class="gmail_msg">
><br class="gmail_msg">
> Basically, embedding a web server and reverse proxying for it isolates the application from the frontend server and simplifies the management of both.<br class="gmail_msg">
<br class="gmail_msg">
I’m not really sure this is a pros or cons. Having to run multiple processes and use sockets increase code complexity and surface for attacks. It increase the number of services started so the number of processes to watch.<br class="gmail_msg">
<br class="gmail_msg">
In some scenario, this is better, in some others, this is worst.<br class="gmail_msg">
<br class="gmail_msg">
As I’ve said on my first e-mail, I don’t say standalone swift HTTP server must not exist. I’ve just said it could be interesting to think about others patterns.<br class="gmail_msg">
<br class="gmail_msg">
Allowing behavior like WSGI where you can use both scenario is IMHO the best solution ever, so it can fit for all needs.<br class="gmail_msg">
<br class="gmail_msg">
Best regards,<br class="gmail_msg">
Yoann Gini<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
------------------------------<br class="gmail_msg">
<br class="gmail_msg">
Message: 20<br class="gmail_msg">
Date: Wed, 26 Oct 2016 12:39:01 +0100<br class="gmail_msg">
From: Chris Bailey <<a href="mailto:BAILEYC@uk.ibm.com" class="gmail_msg" target="_blank">BAILEYC@uk.ibm.com</a>><br class="gmail_msg">
To: Helge Heß <<a href="mailto:me@helgehess.eu" class="gmail_msg" target="_blank">me@helgehess.eu</a>><br class="gmail_msg">
Cc: <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
Subject: Re: [swift-server-dev] Database API/Framework<br class="gmail_msg">
Message-ID:<br class="gmail_msg">
<<a href="mailto:OF4B342709.861A5D1A-ON80258058.00369FEC-80258058.003FFEF3@notes.na.collabserv.com" class="gmail_msg" target="_blank">OF4B342709.861A5D1A-ON80258058.00369FEC-80258058.003FFEF3@notes.na.collabserv.com</a>><br class="gmail_msg">
<br class="gmail_msg">
Content-Type: text/plain; charset="utf-8"<br class="gmail_msg">
<br class="gmail_msg">
Hi Helge:<br class="gmail_msg">
<br class="gmail_msg">
As the initial target areas are low-level function, yes, each of the<br class="gmail_msg">
frameworks has an implementation of most of them today. Those<br class="gmail_msg">
implementations tend to be limited in a number of ways:<br class="gmail_msg">
C libraries are often used directly (via a modulemap)<br class="gmail_msg">
This means that there's no general "Swift API" that developers can use -<br class="gmail_msg">
you have to interface with the C APIs directly and deal with<br class="gmail_msg">
Unsafe/OpaquePointers etc. Ideally we want Swift developers to only have<br class="gmail_msg">
to write Swift code<br class="gmail_msg">
Where a Swift API wraps a C library its generally for a specific use case<br class="gmail_msg">
As the framework teams have a very specific use case - using it in their<br class="gmail_msg">
framework - the APIs are very directed to what they need to do, rather<br class="gmail_msg">
than being general purpose for a wider set of use cases<br class="gmail_msg">
There's multiple, similar, packages<br class="gmail_msg">
Most frameworks have their own server socket implementation (mostly by<br class="gmail_msg">
calling Glibc and Darwin), HTTP parser implementation, etc. Not only does<br class="gmail_msg">
this mean we can consolidate the efforts on a single implementation, but<br class="gmail_msg">
it means that anyone wanting to add additional platform support (like<br class="gmail_msg">
Windows) only has to do so once.<br class="gmail_msg">
<br class="gmail_msg">
Chris<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
From: Helge Heß via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>><br class="gmail_msg">
To: <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
Date: 25/10/2016 19:57<br class="gmail_msg">
Subject: Re: [swift-server-dev] Database API/Framework<br class="gmail_msg">
Sent by: <a href="mailto:swift-server-dev-bounces@swift.org" class="gmail_msg" target="_blank">swift-server-dev-bounces@swift.org</a><br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
Hi Chris,<br class="gmail_msg">
<br class="gmail_msg">
it is a little unclear what the scope of the group is. Presumably you have<br class="gmail_msg">
some very specific things in mind?<br class="gmail_msg">
<br class="gmail_msg">
Of course we’ve seen <a href="https://swift.org/server-apis/#focus-areas" rel="noreferrer" class="gmail_msg" target="_blank">https://swift.org/server-apis/#focus-areas</a>. But what<br class="gmail_msg">
does it actually mean? :-) Looking at it:<br class="gmail_msg">
- base networking: TCP/UDP, DNS. Covered already by libdispatch and the<br class="gmail_msg">
OS’ses?<br class="gmail_msg">
- security: OpenSSL? or some wrapper around both, CC and OpenSSL?<br class="gmail_msg">
- provide low level HTTP parsing: http_parser? Is anyone using something<br class="gmail_msg">
else?<br class="gmail_msg">
All that seems kinda covered/standard already? Unless maybe you include<br class="gmail_msg">
non-Unix stuff like Windows.<br class="gmail_msg">
<br class="gmail_msg">
Is this primarily for things like providing a standardised ’swiftier'<br class="gmail_msg">
OpenSSL wrapper (similar to how Objective-GCD wraps libdispatch)?<br class="gmail_msg">
Or would that just be module maps which are shipped by default with Swift<br class="gmail_msg">
and hence can be relied on by all frameworks?<br class="gmail_msg">
<br class="gmail_msg">
But maybe I’m just a little too impatient :-><br class="gmail_msg">
<br class="gmail_msg">
hh<br class="gmail_msg">
<br class="gmail_msg">
> On 25 Oct 2016, at 20:41, Chris Bailey via swift-server-dev<br class="gmail_msg">
<<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
> Hi Ron:<br class="gmail_msg">
><br class="gmail_msg">
> As you say, that's outside of the scope of the work group, however I do<br class="gmail_msg">
think its a valuable area that the various existing web framework groups<br class="gmail_msg">
might be interested in collaborating on. Having a common, recognized<br class="gmail_msg">
framework that the database providers or third parties would be interested<br class="gmail_msg">
in writing database drivers for would be a huge step forward.<br class="gmail_msg">
><br class="gmail_msg">
> I know that Vapor has its Fluent ORM framework, and that its an area<br class="gmail_msg">
that the Kitura team are looking at as well, so your post might kick-start<br class="gmail_msg">
some wider discussion.<br class="gmail_msg">
><br class="gmail_msg">
> Chris<br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> From: Ron Olson via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>><br class="gmail_msg">
<br class="gmail_msg">
> To: <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
> Date: 25/10/2016 18:54<br class="gmail_msg">
> Subject: [swift-server-dev] Database API/Framework<br class="gmail_msg">
> Sent by: <a href="mailto:swift-server-dev-bounces@swift.org" class="gmail_msg" target="_blank">swift-server-dev-bounces@swift.org</a><br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> Hi all-<br class="gmail_msg">
><br class="gmail_msg">
> I've been working with Swift more on Linux than macOS and am very<br class="gmail_msg">
> excited to see the formation of this group. Looking at the server api<br class="gmail_msg">
> workgroup's focus, I notice it's primarily low-level interaction with<br class="gmail_msg">
> the operating system. When might it be a good time to bring up the<br class="gmail_msg">
> possibility of creating a database-specific framework for those folks<br class="gmail_msg">
> who want to work directly with Postgres, MySQL, even DB2 and Oracle; I'm<br class="gmail_msg">
<br class="gmail_msg">
> thinking a JDBC-inspired framework that drivers could be written<br class="gmail_msg">
> against.<br class="gmail_msg">
><br class="gmail_msg">
> Thanks,<br class="gmail_msg">
><br class="gmail_msg">
> Ron<br class="gmail_msg">
> _______________________________________________<br class="gmail_msg">
> swift-server-dev mailing list<br class="gmail_msg">
> <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
> <a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-server-dev</a><br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> _______________________________________________<br class="gmail_msg">
> swift-server-dev mailing list<br class="gmail_msg">
> <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
> <a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-server-dev</a><br class="gmail_msg">
<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
swift-server-dev mailing list<br class="gmail_msg">
<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-server-dev</a><br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
-------------- next part --------------<br class="gmail_msg">
An HTML attachment was scrubbed...<br class="gmail_msg">
URL: <<a href="https://lists.swift.org/pipermail/swift-server-dev/attachments/20161026/f87a0fbc/attachment-0001.html" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/pipermail/swift-server-dev/attachments/20161026/f87a0fbc/attachment-0001.html</a>><br class="gmail_msg">
<br class="gmail_msg">
------------------------------<br class="gmail_msg">
<br class="gmail_msg">
Message: 21<br class="gmail_msg">
Date: Wed, 26 Oct 2016 14:35:03 +0100<br class="gmail_msg">
From: Gregor Milos <<a href="mailto:gmilos@apple.com" class="gmail_msg" target="_blank">gmilos@apple.com</a>><br class="gmail_msg">
To: Chris Bailey <<a href="mailto:BAILEYC@uk.ibm.com" class="gmail_msg" target="_blank">BAILEYC@uk.ibm.com</a>><br class="gmail_msg">
Cc: <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
Subject: Re: [swift-server-dev] Database API/Framework<br class="gmail_msg">
Message-ID: <<a href="mailto:C2BA24EC-223C-4518-AD1E-057EB1585FAC@apple.com" class="gmail_msg" target="_blank">C2BA24EC-223C-4518-AD1E-057EB1585FAC@apple.com</a>><br class="gmail_msg">
Content-Type: text/plain; charset=utf-8<br class="gmail_msg">
<br class="gmail_msg">
Helge,<br class="gmail_msg">
<br class="gmail_msg">
Expand on Chris's answer, modern languages used on server side come with abstractions native to their language. Taking the example of of HTTP protocol:<br class="gmail_msg">
* Go comes with <a href="https://golang.org/pkg/net/http/" rel="noreferrer" class="gmail_msg" target="_blank">https://golang.org/pkg/net/http/</a><br class="gmail_msg">
* Netty (defacto standard Java net lib) comes with: <a href="http://netty.io/4.1/api/io/netty/handler/codec/http/package-frame.html" rel="noreferrer" class="gmail_msg" target="_blank">http://netty.io/4.1/api/io/netty/handler/codec/http/package-frame.html</a><br class="gmail_msg">
* etc ...<br class="gmail_msg">
Our task should be to design an API that works well in Swift. Node's http_parser is "just" an example of an API and a possible way of accelerating the implementation of Swift's HTTP parser.<br class="gmail_msg">
<br class="gmail_msg">
Thanks<br class="gmail_msg">
Gregor<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
> On 26 Oct 2016, at 12:39, Chris Bailey via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
> Hi Helge:<br class="gmail_msg">
><br class="gmail_msg">
> 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:<br class="gmail_msg">
> • C libraries are often used directly (via a modulemap)<br class="gmail_msg">
> 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<br class="gmail_msg">
> • Where a Swift API wraps a C library its generally for a specific use case<br class="gmail_msg">
> 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<br class="gmail_msg">
> • There's multiple, similar, packages<br class="gmail_msg">
> 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.<br class="gmail_msg">
><br class="gmail_msg">
> Chris<br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> From: Helge Heß via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>><br class="gmail_msg">
> To: <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
> Date: 25/10/2016 19:57<br class="gmail_msg">
> Subject: Re: [swift-server-dev] Database API/Framework<br class="gmail_msg">
> Sent by: <a href="mailto:swift-server-dev-bounces@swift.org" class="gmail_msg" target="_blank">swift-server-dev-bounces@swift.org</a><br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> Hi Chris,<br class="gmail_msg">
><br class="gmail_msg">
> it is a little unclear what the scope of the group is. Presumably you have some very specific things in mind?<br class="gmail_msg">
><br class="gmail_msg">
> Of course we’ve seen <a href="https://swift.org/server-apis/#focus-areas" rel="noreferrer" class="gmail_msg" target="_blank">https://swift.org/server-apis/#focus-areas</a>. But what does it actually mean? :-) Looking at it:<br class="gmail_msg">
> - base networking: TCP/UDP, DNS. Covered already by libdispatch and the OS’ses?<br class="gmail_msg">
> - security: OpenSSL? or some wrapper around both, CC and OpenSSL?<br class="gmail_msg">
> - provide low level HTTP parsing: http_parser? Is anyone using something<br class="gmail_msg">
> else?<br class="gmail_msg">
> All that seems kinda covered/standard already? Unless maybe you include non-Unix stuff like Windows.<br class="gmail_msg">
><br class="gmail_msg">
> Is this primarily for things like providing a standardised ’swiftier' OpenSSL wrapper (similar to how Objective-GCD wraps libdispatch)?<br class="gmail_msg">
> Or would that just be module maps which are shipped by default with Swift and hence can be relied on by all frameworks?<br class="gmail_msg">
><br class="gmail_msg">
> But maybe I’m just a little too impatient :-><br class="gmail_msg">
><br class="gmail_msg">
> hh<br class="gmail_msg">
><br class="gmail_msg">
> > On 25 Oct 2016, at 20:41, Chris Bailey via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>> wrote:<br class="gmail_msg">
> ><br class="gmail_msg">
> > Hi Ron:<br class="gmail_msg">
> ><br class="gmail_msg">
> > 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.<br class="gmail_msg">
> ><br class="gmail_msg">
> > 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.<br class="gmail_msg">
> ><br class="gmail_msg">
> > Chris<br class="gmail_msg">
> ><br class="gmail_msg">
> ><br class="gmail_msg">
> ><br class="gmail_msg">
> ><br class="gmail_msg">
> > From: Ron Olson via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>><br class="gmail_msg">
> > To: <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
> > Date: 25/10/2016 18:54<br class="gmail_msg">
> > Subject: [swift-server-dev] Database API/Framework<br class="gmail_msg">
> > Sent by: <a href="mailto:swift-server-dev-bounces@swift.org" class="gmail_msg" target="_blank">swift-server-dev-bounces@swift.org</a><br class="gmail_msg">
> ><br class="gmail_msg">
> ><br class="gmail_msg">
> ><br class="gmail_msg">
> > Hi all-<br class="gmail_msg">
> ><br class="gmail_msg">
> > I've been working with Swift more on Linux than macOS and am very<br class="gmail_msg">
> > excited to see the formation of this group. Looking at the server api<br class="gmail_msg">
> > workgroup's focus, I notice it's primarily low-level interaction with<br class="gmail_msg">
> > the operating system. When might it be a good time to bring up the<br class="gmail_msg">
> > possibility of creating a database-specific framework for those folks<br class="gmail_msg">
> > who want to work directly with Postgres, MySQL, even DB2 and Oracle; I'm<br class="gmail_msg">
> > thinking a JDBC-inspired framework that drivers could be written<br class="gmail_msg">
> > against.<br class="gmail_msg">
> ><br class="gmail_msg">
> > Thanks,<br class="gmail_msg">
> ><br class="gmail_msg">
> > Ron<br class="gmail_msg">
> > _______________________________________________<br class="gmail_msg">
> > swift-server-dev mailing list<br class="gmail_msg">
> > <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
> > <a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-server-dev</a><br class="gmail_msg">
> ><br class="gmail_msg">
> ><br class="gmail_msg">
> > _______________________________________________<br class="gmail_msg">
> > swift-server-dev mailing list<br class="gmail_msg">
> > <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
> > <a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-server-dev</a><br class="gmail_msg">
><br class="gmail_msg">
> _______________________________________________<br class="gmail_msg">
> swift-server-dev mailing list<br class="gmail_msg">
> <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
> <a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-server-dev</a><br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> _______________________________________________<br class="gmail_msg">
> swift-server-dev mailing list<br class="gmail_msg">
> <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
> <a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-server-dev</a><br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
------------------------------<br class="gmail_msg">
<br class="gmail_msg">
Message: 22<br class="gmail_msg">
Date: Wed, 26 Oct 2016 14:41:00 +0100<br class="gmail_msg">
From: Gregor Milos <<a href="mailto:gmilos@apple.com" class="gmail_msg" target="_blank">gmilos@apple.com</a>><br class="gmail_msg">
To: Gregor Milos <<a href="mailto:gmilos@apple.com" class="gmail_msg" target="_blank">gmilos@apple.com</a>><br class="gmail_msg">
Cc: <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
Subject: Re: [swift-server-dev] Database API/Framework<br class="gmail_msg">
Message-ID: <<a href="mailto:A338CA7D-6E7E-4D1E-B10C-C81764DDD909@apple.com" class="gmail_msg" target="_blank">A338CA7D-6E7E-4D1E-B10C-C81764DDD909@apple.com</a>><br class="gmail_msg">
Content-Type: text/plain; CHARSET=US-ASCII<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
> On 26 Oct 2016, at 14:35, Gregor Milos via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
> Expand<br class="gmail_msg">
s/Expand/Expanding/<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
------------------------------<br class="gmail_msg">
<br class="gmail_msg">
Message: 23<br class="gmail_msg">
Date: Wed, 26 Oct 2016 16:39:20 +0200<br class="gmail_msg">
From: Helge Heß <<a href="mailto:me@helgehess.eu" class="gmail_msg" target="_blank">me@helgehess.eu</a>><br class="gmail_msg">
To: Paulo Faria via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>><br class="gmail_msg">
Subject: Re: [swift-server-dev] Database API/Framework<br class="gmail_msg">
Message-ID: <<a href="mailto:C7A408BB-7EAC-4573-A01F-343588116F77@helgehess.eu" class="gmail_msg" target="_blank">C7A408BB-7EAC-4573-A01F-343588116F77@helgehess.eu</a>><br class="gmail_msg">
Content-Type: text/plain; charset="utf-8"<br class="gmail_msg">
<br class="gmail_msg">
Hi Gregor,<br class="gmail_msg">
<br class="gmail_msg">
On 26 Oct 2016, at 15:35, Gregor Milos <<a href="mailto:gmilos@apple.com" class="gmail_msg" target="_blank">gmilos@apple.com</a>> wrote:<br class="gmail_msg">
> Expand on Chris's answer, modern languages used on server side come with abstractions native to their language.<br class="gmail_msg">
<br class="gmail_msg">
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 … :-)<br class="gmail_msg">
<br class="gmail_msg">
> * Netty (defacto standard Java net lib)<br class="gmail_msg">
<br class="gmail_msg">
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).<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
OK OK, nitpicking aside, so the goal this:<br class="gmail_msg">
<br class="gmail_msg">
> Our task should be to design an API that works well in Swift.<br class="gmail_msg">
<br class="gmail_msg">
Understood. So the plan is indeed to replace the kernel of the HL frameworks with a common Swift `http` server module. A peer to <a href="https://golang.org/pkg/net/http/" rel="noreferrer" class="gmail_msg" target="_blank">https://golang.org/pkg/net/http/</a>. Fair enough.<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
> Node's http_parser is "just" an example of an API and a possible way of accelerating the implementation of Swift's HTTP parser.<br class="gmail_msg">
<br class="gmail_msg">
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.<br class="gmail_msg">
<br class="gmail_msg">
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).<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
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.<br class="gmail_msg">
<br class="gmail_msg">
hh<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
>> On 26 Oct 2016, at 12:39, Chris Bailey via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>> wrote:<br class="gmail_msg">
>><br class="gmail_msg">
>> Hi Helge:<br class="gmail_msg">
>><br class="gmail_msg">
>> 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:<br class="gmail_msg">
>> • C libraries are often used directly (via a modulemap)<br class="gmail_msg">
>> 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<br class="gmail_msg">
>> • Where a Swift API wraps a C library its generally for a specific use case<br class="gmail_msg">
>> 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<br class="gmail_msg">
>> • There's multiple, similar, packages<br class="gmail_msg">
>> 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.<br class="gmail_msg">
>><br class="gmail_msg">
>> Chris<br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>> From: Helge Heß via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>><br class="gmail_msg">
>> To: <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
>> Date: 25/10/2016 19:57<br class="gmail_msg">
>> Subject: Re: [swift-server-dev] Database API/Framework<br class="gmail_msg">
>> Sent by: <a href="mailto:swift-server-dev-bounces@swift.org" class="gmail_msg" target="_blank">swift-server-dev-bounces@swift.org</a><br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>> Hi Chris,<br class="gmail_msg">
>><br class="gmail_msg">
>> it is a little unclear what the scope of the group is. Presumably you have some very specific things in mind?<br class="gmail_msg">
>><br class="gmail_msg">
>> Of course we’ve seen <a href="https://swift.org/server-apis/#focus-areas" rel="noreferrer" class="gmail_msg" target="_blank">https://swift.org/server-apis/#focus-areas</a>. But what does it actually mean? :-) Looking at it:<br class="gmail_msg">
>> - base networking: TCP/UDP, DNS. Covered already by libdispatch and the OS’ses?<br class="gmail_msg">
>> - security: OpenSSL? or some wrapper around both, CC and OpenSSL?<br class="gmail_msg">
>> - provide low level HTTP parsing: http_parser? Is anyone using something<br class="gmail_msg">
>> else?<br class="gmail_msg">
>> All that seems kinda covered/standard already? Unless maybe you include non-Unix stuff like Windows.<br class="gmail_msg">
>><br class="gmail_msg">
>> Is this primarily for things like providing a standardised ’swiftier' OpenSSL wrapper (similar to how Objective-GCD wraps libdispatch)?<br class="gmail_msg">
>> Or would that just be module maps which are shipped by default with Swift and hence can be relied on by all frameworks?<br class="gmail_msg">
>><br class="gmail_msg">
>> But maybe I’m just a little too impatient :-><br class="gmail_msg">
>><br class="gmail_msg">
>> hh<br class="gmail_msg">
>><br class="gmail_msg">
>>> On 25 Oct 2016, at 20:41, Chris Bailey via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>> wrote:<br class="gmail_msg">
>>><br class="gmail_msg">
>>> Hi Ron:<br class="gmail_msg">
>>><br class="gmail_msg">
>>> 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.<br class="gmail_msg">
>>><br class="gmail_msg">
>>> 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.<br class="gmail_msg">
>>><br class="gmail_msg">
>>> Chris<br class="gmail_msg">
>>><br class="gmail_msg">
>>><br class="gmail_msg">
>>><br class="gmail_msg">
>>><br class="gmail_msg">
>>> From: Ron Olson via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>><br class="gmail_msg">
>>> To: <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
>>> Date: 25/10/2016 18:54<br class="gmail_msg">
>>> Subject: [swift-server-dev] Database API/Framework<br class="gmail_msg">
>>> Sent by: <a href="mailto:swift-server-dev-bounces@swift.org" class="gmail_msg" target="_blank">swift-server-dev-bounces@swift.org</a><br class="gmail_msg">
>>><br class="gmail_msg">
>>><br class="gmail_msg">
>>><br class="gmail_msg">
>>> Hi all-<br class="gmail_msg">
>>><br class="gmail_msg">
>>> I've been working with Swift more on Linux than macOS and am very<br class="gmail_msg">
>>> excited to see the formation of this group. Looking at the server api<br class="gmail_msg">
>>> workgroup's focus, I notice it's primarily low-level interaction with<br class="gmail_msg">
>>> the operating system. When might it be a good time to bring up the<br class="gmail_msg">
>>> possibility of creating a database-specific framework for those folks<br class="gmail_msg">
>>> who want to work directly with Postgres, MySQL, even DB2 and Oracle; I'm<br class="gmail_msg">
>>> thinking a JDBC-inspired framework that drivers could be written<br class="gmail_msg">
>>> against.<br class="gmail_msg">
>>><br class="gmail_msg">
>>> Thanks,<br class="gmail_msg">
>>><br class="gmail_msg">
>>> Ron<br class="gmail_msg">
>>> _______________________________________________<br class="gmail_msg">
>>> swift-server-dev mailing list<br class="gmail_msg">
>>> <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
>>> <a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-server-dev</a><br class="gmail_msg">
>>><br class="gmail_msg">
>>><br class="gmail_msg">
>>> _______________________________________________<br class="gmail_msg">
>>> swift-server-dev mailing list<br class="gmail_msg">
>>> <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
>>> <a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-server-dev</a><br class="gmail_msg">
>><br class="gmail_msg">
>> _______________________________________________<br class="gmail_msg">
>> swift-server-dev mailing list<br class="gmail_msg">
>> <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
>> <a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-server-dev</a><br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>> _______________________________________________<br class="gmail_msg">
>> swift-server-dev mailing list<br class="gmail_msg">
>> <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
>> <a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-server-dev</a><br class="gmail_msg">
><br class="gmail_msg">
<br class="gmail_msg">
-------------- next part --------------<br class="gmail_msg">
A non-text attachment was scrubbed...<br class="gmail_msg">
Name: signature.asc<br class="gmail_msg">
Type: application/pgp-signature<br class="gmail_msg">
Size: 842 bytes<br class="gmail_msg">
Desc: Message signed with OpenPGP using GPGMail<br class="gmail_msg">
URL: <<a href="https://lists.swift.org/pipermail/swift-server-dev/attachments/20161026/edc8b416/attachment-0001.sig" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/pipermail/swift-server-dev/attachments/20161026/edc8b416/attachment-0001.sig</a>><br class="gmail_msg">
<br class="gmail_msg">
------------------------------<br class="gmail_msg">
<br class="gmail_msg">
Message: 24<br class="gmail_msg">
Date: Wed, 26 Oct 2016 16:52:42 +0200<br class="gmail_msg">
From: Benedikt Terhechte <<a href="mailto:terhechte@me.com" class="gmail_msg" target="_blank">terhechte@me.com</a>><br class="gmail_msg">
To: <a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
Subject: [swift-server-dev] Async I/O in Rust Tokio<br class="gmail_msg">
Message-ID: <<a href="mailto:F8F240BF-A133-4D1B-A1CA-08B1457E591F@me.com" class="gmail_msg" target="_blank">F8F240BF-A133-4D1B-A1CA-08B1457E591F@me.com</a>><br class="gmail_msg">
Content-Type: text/plain; charset=utf-8<br class="gmail_msg">
<br class="gmail_msg">
Hey,<br class="gmail_msg">
<br class="gmail_msg">
I’m a huge fan of server-side Swift and I feel that there is a lot of potential for Swift to grow in this area. So I’m really looking forward to the outcome of this discussion.<br class="gmail_msg">
<br class="gmail_msg">
I’m also a passive observer in the world of Rust, and one thing that recently really impressed was their async I/O library “Tokio”. It is a fairly low level implementation of async I/O and futures in order to be able to build all kinds of networking implementations on top of it:<br class="gmail_msg">
<br class="gmail_msg">
"Tokio is an async I/O stack in Rust running the full gamut in terms of what it provides. At the very bottom you'll find the tokio-core crate with a bare-bones event loop and Future spawning. Near the top you'll find the tokio-proto crate with generic implementations of protocol details like pipelining and multiplexing used to serve requests to the Service trait intokio-service inspired by Finagle.”<br class="gmail_msg">
<br class="gmail_msg">
<a href="https://github.com/tokio-rs/tokio" rel="noreferrer" class="gmail_msg" target="_blank">https://github.com/tokio-rs/tokio</a><br class="gmail_msg">
<br class="gmail_msg">
What I find particularly interesting here is the architecture of Tokio and the broad applications this low level library offers for high level frameworks. Also, the performance seems to be extraordinary good.<br class="gmail_msg">
<br class="gmail_msg">
I wanted mainly to raise awareness for this implementation to see if there’s something interest we could learn from it. I remember that Rust did a lot of experimentation in the async I/O area until they implemented Tokio.<br class="gmail_msg">
<br class="gmail_msg">
Cheers,<br class="gmail_msg">
Benedikt<br class="gmail_msg">
<br class="gmail_msg">
------------------------------<br class="gmail_msg">
<br class="gmail_msg">
Message: 25<br class="gmail_msg">
Date: Wed, 26 Oct 2016 16:31:34 +0100<br class="gmail_msg">
From: Gregor Milos <<a href="mailto:gmilos@apple.com" class="gmail_msg" target="_blank">gmilos@apple.com</a>><br class="gmail_msg">
To: Helge Heß <<a href="mailto:me@helgehess.eu" class="gmail_msg" target="_blank">me@helgehess.eu</a>><br class="gmail_msg">
Cc: Paulo Faria via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>><br class="gmail_msg">
Subject: Re: [swift-server-dev] Database API/Framework<br class="gmail_msg">
Message-ID: <<a href="mailto:D7BE19C8-9169-4B5A-95E2-55B19E927BA0@apple.com" class="gmail_msg" target="_blank">D7BE19C8-9169-4B5A-95E2-55B19E927BA0@apple.com</a>><br class="gmail_msg">
Content-Type: text/plain; charset=utf-8<br class="gmail_msg">
<br class="gmail_msg">
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.<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
Some more comments inline:<br class="gmail_msg">
<br class="gmail_msg">
> On 26 Oct 2016, at 15:39, Helge Heß via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
> Hi Gregor,<br class="gmail_msg">
><br class="gmail_msg">
> On 26 Oct 2016, at 15:35, Gregor Milos <<a href="mailto:gmilos@apple.com" class="gmail_msg" target="_blank">gmilos@apple.com</a>> wrote:<br class="gmail_msg">
>> Expand on Chris's answer, modern languages used on server side come with abstractions native to their language.<br class="gmail_msg">
><br class="gmail_msg">
> 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 … :-)<br class="gmail_msg">
><br class="gmail_msg">
>> * Netty (defacto standard Java net lib)<br class="gmail_msg">
><br class="gmail_msg">
> 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).<br class="gmail_msg">
<br class="gmail_msg">
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. <a href="https://swift.org/server-apis/" rel="noreferrer" class="gmail_msg" target="_blank">https://swift.org/server-apis/</a> talks about the process somewhat, but where the code belongs will largely depend on what it evolves to look like.<br class="gmail_msg">
<br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> OK OK, nitpicking aside, so the goal this:<br class="gmail_msg">
><br class="gmail_msg">
>> Our task should be to design an API that works well in Swift.<br class="gmail_msg">
><br class="gmail_msg">
> Understood. So the plan is indeed to replace the kernel of the HL frameworks with a common Swift `http` server module. A peer to <a href="https://golang.org/pkg/net/http/" rel="noreferrer" class="gmail_msg" target="_blank">https://golang.org/pkg/net/http/</a>. Fair enough.<br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
>> Node's http_parser is "just" an example of an API and a possible way of accelerating the implementation of Swift's HTTP parser.<br class="gmail_msg">
><br class="gmail_msg">
> 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.<br class="gmail_msg">
<br class="gmail_msg">
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 <a href="https://swift.org/documentation/api-design-guidelines/" rel="noreferrer" class="gmail_msg" target="_blank">https://swift.org/documentation/api-design-guidelines/</a>.<br class="gmail_msg">
<br class="gmail_msg">
Hope this all makes sense.<br class="gmail_msg">
Gregor<br class="gmail_msg">
<br class="gmail_msg">
><br class="gmail_msg">
> 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).<br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> 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.<br class="gmail_msg">
><br class="gmail_msg">
> hh<br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
>>> On 26 Oct 2016, at 12:39, Chris Bailey via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>> wrote:<br class="gmail_msg">
>>><br class="gmail_msg">
>>> Hi Helge:<br class="gmail_msg">
>>><br class="gmail_msg">
>>> 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:<br class="gmail_msg">
>>> • C libraries are often used directly (via a modulemap)<br class="gmail_msg">
>>> 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<br class="gmail_msg">
>>> • Where a Swift API wraps a C library its generally for a specific use case<br class="gmail_msg">
>>> As the framework teams have a very specific use case - using it in their framework - the APIs ar</blockquote></div>