[swift-server-dev] swift-server-dev Digest, Vol 1, Issue 1
Logan Wright
logan at qutheory.io
Wed Oct 26 17:12:20 CDT 2016
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.
- Logan
On Wed, Oct 26, 2016 at 1:01 PM <swift-server-dev-request at swift.org> wrote:
> Send swift-server-dev mailing list submissions to
> swift-server-dev at swift.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.swift.org/mailman/listinfo/swift-server-dev
> or, via email, send a message with subject or body 'help' to
> swift-server-dev-request at swift.org
>
> You can reach the person managing the list at
> swift-server-dev-owner at swift.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of swift-server-dev digest..."
>
>
> Today's Topics:
>
> 1. Developing Server APIs for Swift (Chris Bailey)
> 2. Database API/Framework (Ron Olson)
> 3. Re: Database API/Framework (Chris Bailey)
> 4. Re: Database API/Framework (Helge Heß)
> 5. [Bug] Foundation.URL should support semicolon(; ) appearing
> in URL path (frogcjn at 163.com)
> 6. Re: Database API/Framework (Paulo Faria)
> 7. Re: Database API/Framework (Haris Amin)
> 8. Re: Database API/Framework (Helge Heß)
> 9. Re: Database API/Framework (Ron Olson)
> 10. Re: [Bug] Foundation.URL should support semicolon(; )
> appearing in URL path (Alex Blewitt)
> 11. Spring and Baratine (Java frameworks) (Rick Mann)
> 12. Lib dispatch and Edge (Tyler Cloutier)
> 13. Why not rely on existing models? (Yoann Gini)
> 14. Re: Why not rely on existing models? (Helge Heß)
> 15. Re: Database API/Framework (Brent Royal-Gordon)
> 16. Re: Why not rely on existing models? (Yoann Gini)
> 17. Re: Why not rely on existing models? (Brent Royal-Gordon)
> 18. Re: Database API/Framework (Helge Heß)
> 19. Re: Why not rely on existing models? (Yoann Gini)
> 20. Re: Database API/Framework (Chris Bailey)
> 21. Re: Database API/Framework (Gregor Milos)
> 22. Re: Database API/Framework (Gregor Milos)
> 23. Re: Database API/Framework (Helge Heß)
> 24. Async I/O in Rust Tokio (Benedikt Terhechte)
> 25. Re: Database API/Framework (Gregor Milos)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 25 Oct 2016 18:18:40 +0100
> From: Chris Bailey <BAILEYC at uk.ibm.com>
> To: swift-server-dev at swift.org
> Subject: [swift-server-dev] Developing Server APIs for Swift
> Message-ID:
> <
> OFF7B5F3A2.286E27A8-ON80258057.005E33D7-80258057.005F17AB at notes.na.collabserv.com
> >
>
> Content-Type: text/plain; charset="utf-8"
>
> A new project and work group has just been announced, aimed at providing a
> framework for participants in the community with an interest in building
> server applications and frameworks to come together to work on providing
> new Swift APIs.
> https://swift.org/blog/server-api-workgroup/
>
> Whilst there is already strong participation from some of the more well
> know web frameworks, including Kitura, Vapor, Perfect, and Zewo,
> participation and contribution is open to everyone - whether that's having
> a requirement or use case you'd like to share, bugs you want to report
> (once we have code!), code your willing to write, or just your thoughts on
> what's needed.
>
> Chris
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.swift.org/pipermail/swift-server-dev/attachments/20161025/89b49b87/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Tue, 25 Oct 2016 12:53:56 -0500
> From: "Ron Olson" <tachoknight at gmail.com>
> To: swift-server-dev at swift.org
> Subject: [swift-server-dev] Database API/Framework
> Message-ID: <014CED77-5B93-4EF1-A089-EF4926CCF47C at gmail.com>
> Content-Type: text/plain; format=flowed
>
> Hi all-
>
> I've been working with Swift more on Linux than macOS and am very
> excited to see the formation of this group. Looking at the server api
> workgroup's focus, I notice it's primarily low-level interaction with
> the operating system. When might it be a good time to bring up the
> possibility of creating a database-specific framework for those folks
> who want to work directly with Postgres, MySQL, even DB2 and Oracle; I'm
> thinking a JDBC-inspired framework that drivers could be written
> against.
>
> Thanks,
>
> Ron
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 25 Oct 2016 19:41:32 +0100
> From: Chris Bailey <BAILEYC at uk.ibm.com>
> To: Ron Olson <tachoknight at gmail.com>
> Cc: swift-server-dev at swift.org
> Subject: Re: [swift-server-dev] Database API/Framework
> Message-ID:
> <
> OFCED025F9.33D57EE8-ON80258057.00662CA1-80258057.0066ADD2 at notes.na.collabserv.com
> >
>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Ron:
>
> As you say, that's outside of the scope of the work group, however I do
> think its a valuable area that the various existing web framework groups
> might be interested in collaborating on. Having a common, recognized
> framework that the database providers or third parties would be interested
> in writing database drivers for would be a huge step forward.
>
> I know that Vapor has its Fluent ORM framework, and that its an area that
> the Kitura team are looking at as well, so your post might kick-start some
> wider discussion.
>
> Chris
>
>
>
>
> From: Ron Olson via swift-server-dev <swift-server-dev at swift.org>
> To: swift-server-dev at swift.org
> Date: 25/10/2016 18:54
> Subject: [swift-server-dev] Database API/Framework
> Sent by: swift-server-dev-bounces at swift.org
>
>
>
> Hi all-
>
> I've been working with Swift more on Linux than macOS and am very
> excited to see the formation of this group. Looking at the server api
> workgroup's focus, I notice it's primarily low-level interaction with
> the operating system. When might it be a good time to bring up the
> possibility of creating a database-specific framework for those folks
> who want to work directly with Postgres, MySQL, even DB2 and Oracle; I'm
> thinking a JDBC-inspired framework that drivers could be written
> against.
>
> Thanks,
>
> Ron
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-server-dev
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.swift.org/pipermail/swift-server-dev/attachments/20161025/59d5ff21/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 4
> Date: Tue, 25 Oct 2016 20:56:13 +0200
> From: Helge Heß <me at helgehess.eu>
> To: swift-server-dev at swift.org
> Subject: Re: [swift-server-dev] Database API/Framework
> Message-ID: <0A3EC83B-E26E-49F3-8EDE-E2B85D6836D1 at helgehess.eu>
> Content-Type: text/plain; charset=utf-8
>
> Hi Chris,
>
> it is a little unclear what the scope of the group is. Presumably you have
> some very specific things in mind?
>
> Of course we’ve seen https://swift.org/server-apis/#focus-areas. But what
> does it actually mean? :-) Looking at it:
> - base networking: TCP/UDP, DNS. Covered already by libdispatch and the
> OS’ses?
> - security: OpenSSL? or some wrapper around both, CC and OpenSSL?
> - provide low level HTTP parsing: http_parser? Is anyone using something
> else?
> All that seems kinda covered/standard already? Unless maybe you include
> non-Unix stuff like Windows.
>
> Is this primarily for things like providing a standardised ’swiftier'
> OpenSSL wrapper (similar to how Objective-GCD wraps libdispatch)?
> Or would that just be module maps which are shipped by default with Swift
> and hence can be relied on by all frameworks?
>
> But maybe I’m just a little too impatient :->
>
> hh
>
> > On 25 Oct 2016, at 20:41, Chris Bailey via swift-server-dev <
> swift-server-dev at swift.org> wrote:
> >
> > Hi Ron:
> >
> > As you say, that's outside of the scope of the work group, however I do
> think its a valuable area that the various existing web framework groups
> might be interested in collaborating on. Having a common, recognized
> framework that the database providers or third parties would be interested
> in writing database drivers for would be a huge step forward.
> >
> > I know that Vapor has its Fluent ORM framework, and that its an area
> that the Kitura team are looking at as well, so your post might kick-start
> some wider discussion.
> >
> > Chris
> >
> >
> >
> >
> > From: Ron Olson via swift-server-dev <swift-server-dev at swift.org>
> > To: swift-server-dev at swift.org
> > Date: 25/10/2016 18:54
> > Subject: [swift-server-dev] Database API/Framework
> > Sent by: swift-server-dev-bounces at swift.org
> >
> >
> >
> > Hi all-
> >
> > I've been working with Swift more on Linux than macOS and am very
> > excited to see the formation of this group. Looking at the server api
> > workgroup's focus, I notice it's primarily low-level interaction with
> > the operating system. When might it be a good time to bring up the
> > possibility of creating a database-specific framework for those folks
> > who want to work directly with Postgres, MySQL, even DB2 and Oracle; I'm
> > thinking a JDBC-inspired framework that drivers could be written
> > against.
> >
> > Thanks,
> >
> > Ron
> > _______________________________________________
> > swift-server-dev mailing list
> > swift-server-dev at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-server-dev
> >
> >
> > _______________________________________________
> > swift-server-dev mailing list
> > swift-server-dev at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-server-dev
>
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 26 Oct 2016 03:09:33 +0800
> From: frogcjn at 163.com
> To: swift-server-dev at swift.org
> Subject: [swift-server-dev] [Bug] Foundation.URL should support
> semicolon(; ) appearing in URL path
> Message-ID: <22A5614E-C6ED-47DD-A190-917C49422D02 at 163.com>
> Content-Type: text/plain; charset=us-ascii
>
>
> http://host/book;id=1/page;2/
>
> this URL is a valid URL, but URLComponents will ruin it with %3B
> http://host/book%3Bid=1/page%3B2/
>
> Since Swift Server is coming out, this bug should be solved.
>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 25 Oct 2016 17:20:23 -0200
> From: Paulo Faria <paulo at zewo.io>
> To: Helge Heß <me at helgehess.eu>
> Cc: swift-server-dev at swift.org
> Subject: Re: [swift-server-dev] Database API/Framework
> Message-ID: <78032B27-2CF6-480A-8B21-9EE4C10B8161 at zewo.io>
> Content-Type: text/plain; charset=utf-8
>
> Hello, Helge.
>
> 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.
>
> Cheers,
> Paulo
>
> > On Oct 25, 2016, at 4:56 PM, Helge Heß via swift-server-dev <
> swift-server-dev at swift.org> wrote:
> >
> > Hi Chris,
> >
> > it is a little unclear what the scope of the group is. Presumably you
> have some very specific things in mind?
> >
> > Of course we’ve seen https://swift.org/server-apis/#focus-areas. But
> what does it actually mean? :-) Looking at it:
> > - base networking: TCP/UDP, DNS. Covered already by libdispatch and the
> OS’ses?
> > - security: OpenSSL? or some wrapper around both, CC and OpenSSL?
> > - provide low level HTTP parsing: http_parser? Is anyone using something
> > else?
> > All that seems kinda covered/standard already? Unless maybe you include
> non-Unix stuff like Windows.
> >
> > Is this primarily for things like providing a standardised ’swiftier'
> OpenSSL wrapper (similar to how Objective-GCD wraps libdispatch)?
> > Or would that just be module maps which are shipped by default with
> Swift and hence can be relied on by all frameworks?
> >
> > But maybe I’m just a little too impatient :->
> >
> > hh
> >
> >> On 25 Oct 2016, at 20:41, Chris Bailey via swift-server-dev <
> swift-server-dev at swift.org> wrote:
> >>
> >> Hi Ron:
> >>
> >> As you say, that's outside of the scope of the work group, however I do
> think its a valuable area that the various existing web framework groups
> might be interested in collaborating on. Having a common, recognized
> framework that the database providers or third parties would be interested
> in writing database drivers for would be a huge step forward.
> >>
> >> I know that Vapor has its Fluent ORM framework, and that its an area
> that the Kitura team are looking at as well, so your post might kick-start
> some wider discussion.
> >>
> >> Chris
> >>
> >>
> >>
> >>
> >> From: Ron Olson via swift-server-dev <swift-server-dev at swift.org
> >
> >> To: swift-server-dev at swift.org
> >> Date: 25/10/2016 18:54
> >> Subject: [swift-server-dev] Database API/Framework
> >> Sent by: swift-server-dev-bounces at swift.org
> >>
> >>
> >>
> >> Hi all-
> >>
> >> I've been working with Swift more on Linux than macOS and am very
> >> excited to see the formation of this group. Looking at the server api
> >> workgroup's focus, I notice it's primarily low-level interaction with
> >> the operating system. When might it be a good time to bring up the
> >> possibility of creating a database-specific framework for those folks
> >> who want to work directly with Postgres, MySQL, even DB2 and Oracle; I'm
> >> thinking a JDBC-inspired framework that drivers could be written
> >> against.
> >>
> >> Thanks,
> >>
> >> Ron
> >> _______________________________________________
> >> swift-server-dev mailing list
> >> swift-server-dev at swift.org
> >> https://lists.swift.org/mailman/listinfo/swift-server-dev
> >>
> >>
> >> _______________________________________________
> >> swift-server-dev mailing list
> >> swift-server-dev at swift.org
> >> https://lists.swift.org/mailman/listinfo/swift-server-dev
> >
> > _______________________________________________
> > swift-server-dev mailing list
> > swift-server-dev at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-server-dev
>
>
>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 25 Oct 2016 15:34:24 -0400
> From: Haris Amin <aminharis7 at gmail.com>
> To: Paulo Faria <paulo at zewo.io>, Helge Heß <me at helgehess.eu>, Paulo
> Faria via swift-server-dev <swift-server-dev at swift.org>
> Subject: Re: [swift-server-dev] Database API/Framework
> Message-ID:
> <CAG=aSgQ_byEvJPCcqU=
> kT6LRuT3xXYzk+Laabja2uYnVAaZDHg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hey everyone,
>
> So I’m currently working on a pure Swift Postgres driver. It has no
> dependency on libpq at all. I’m parsing the Postgres Wire Protocol (V3)
> myself and everything seems great. Here are some problems/issues I’m facing
> that db driver implementers like myself (don’t shoot me this is my first
> shot at a db driver ;) ) would like to see resolved by this swift server
> group or we could use some guidance on:
>
> 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. From the blog post it seems like that falls under this groups
> umbrella/objectives
>
> 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?
>
> 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.
>
> 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.
>
> In short, for me at least, these 4 points would be great to be addressed
> (the 4th one perhaps is debatable and not as urgent), for database driver
> authors would greatly help a lot. Pretty much every server side swift
> framework right now has their own ORM-ish libs/frameworks. That’s awesome!
> My hope is we can start writing some of the drivers in pure Swift and help
> all those frameworks/libs get better too.
>
> Just my 2 cents. Perhaps this deserves a thread of its own. Perhaps it
> doesn’t. I apologize in advance if this is distracting from the current
> thread :)
>
> --
> Haris Amin
> Sent with Airmail
>
> On October 25, 2016 at 3:21:07 PM, Paulo Faria via swift-server-dev (
> swift-server-dev at swift.org) wrote:
>
> Hello, Helge.
>
> 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.
>
> Cheers,
> Paulo
>
> > On Oct 25, 2016, at 4:56 PM, Helge Heß via swift-server-dev <
> swift-server-dev at swift.org> wrote:
> >
> > Hi Chris,
> >
> > it is a little unclear what the scope of the group is. Presumably you
> have some very specific things in mind?
> >
> > Of course we’ve seen https://swift.org/server-apis/#focus-areas. But
> what
> does it actually mean? :-) Looking at it:
> > - base networking: TCP/UDP, DNS. Covered already by libdispatch and the
> OS’ses?
> > - security: OpenSSL? or some wrapper around both, CC and OpenSSL?
> > - provide low level HTTP parsing: http_parser? Is anyone using something
> > else?
> > All that seems kinda covered/standard already? Unless maybe you include
> non-Unix stuff like Windows.
> >
> > Is this primarily for things like providing a standardised ’swiftier'
> OpenSSL wrapper (similar to how Objective-GCD wraps libdispatch)?
> > Or would that just be module maps which are shipped by default with Swift
> and hence can be relied on by all frameworks?
> >
> > But maybe I’m just a little too impatient :->
> >
> > hh
> >
> >> On 25 Oct 2016, at 20:41, Chris Bailey via swift-server-dev <
> swift-server-dev at swift.org> wrote:
> >>
> >> Hi Ron:
> >>
> >> As you say, that's outside of the scope of the work group, however I do
> think its a valuable area that the various existing web framework groups
> might be interested in collaborating on. Having a common, recognized
> framework that the database providers or third parties would be interested
> in writing database drivers for would be a huge step forward.
> >>
> >> I know that Vapor has its Fluent ORM framework, and that its an area
> that the Kitura team are looking at as well, so your post might kick-start
> some wider discussion.
> >>
> >> Chris
> >>
> >>
> >>
> >>
> >> From: Ron Olson via swift-server-dev <swift-server-dev at swift.org>
> >> To: swift-server-dev at swift.org
> >> Date: 25/10/2016 18:54
> >> Subject: [swift-server-dev] Database API/Framework
> >> Sent by: swift-server-dev-bounces at swift.org
> >>
> >>
> >>
> >> Hi all-
> >>
> >> I've been working with Swift more on Linux than macOS and am very
> >> excited to see the formation of this group. Looking at the server api
> >> workgroup's focus, I notice it's primarily low-level interaction with
> >> the operating system. When might it be a good time to bring up the
> >> possibility of creating a database-specific framework for those folks
> >> who want to work directly with Postgres, MySQL, even DB2 and Oracle; I'm
> >> thinking a JDBC-inspired framework that drivers could be written
> >> against.
> >>
> >> Thanks,
> >>
> >> Ron
> >> _______________________________________________
> >> swift-server-dev mailing list
> >> swift-server-dev at swift.org
> >> https://lists.swift.org/mailman/listinfo/swift-server-dev
> >>
> >>
> >> _______________________________________________
> >> swift-server-dev mailing list
> >> swift-server-dev at swift.org
> >> https://lists.swift.org/mailman/listinfo/swift-server-dev
> >
> > _______________________________________________
> > swift-server-dev mailing list
> > swift-server-dev at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-server-dev
>
>
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-server-dev
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.swift.org/pipermail/swift-server-dev/attachments/20161025/12d9cfc6/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 8
> Date: Tue, 25 Oct 2016 22:44:03 +0200
> From: Helge Heß <me at helgehess.eu>
> To: Paulo Faria via swift-server-dev <swift-server-dev at swift.org>
> Subject: Re: [swift-server-dev] Database API/Framework
> Message-ID: <96EBE4B7-013D-42E9-BDC4-715BB6ABD1F6 at helgehess.eu>
> Content-Type: text/plain; charset=utf-8
>
> Hi,
>
> On 25 Oct 2016, at 21:34, Haris Amin <aminharis7 at gmail.com> wrote:
> > So I’m currently working on a pure Swift Postgres driver.
>
> nice, I’m working on one as well (currently can run only basic queries,
> nothing fancy).
>
> > 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.
>
> 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
> ;-)
>
> For making the Unix calls a little nicer Swift extensions on the Unix
> types are IMO pretty awesome, something along those lines:
>
>
> https://github.com/NozeIO/Noze.io/blob/master/Sources/net/SocketAddress.swift
>
> I would avoid creating wrappers which are then just wrapped again by the
> higher level frameworks …
>
> 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.
>
>
> > 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?
>
> If it is part of Foundation you can assume it is supposed to work, right?
> :-)
>
>
> > 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.
>
> +1 (And that should probably be part of Foundation as it is required just
> the same on the client side).
>
>
> > 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.
>
> 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.
>
> 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).
>
> > My hope is we can start writing some of the drivers in pure Swift and
> help all those frameworks/libs get better too.
>
> 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.
>
>
> Anywayz, interesting to see what people come up with :-)
>
> hh
>
>
>
> ------------------------------
>
> Message: 9
> Date: Tue, 25 Oct 2016 15:55:23 -0500
> From: "Ron Olson" <tachoknight at gmail.com>
> To: swift-server-dev at swift.org
> Subject: Re: [swift-server-dev] Database API/Framework
> Message-ID: <BA9D7BA9-3E1A-47C3-81E8-8DE02817B74D at gmail.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> I mentioned JDBC because I happened to be looking at some Java code at
> the time, but I really meant 'generic-interface' to provide the
> lowest-level-but-no-lower-than-necessary access to the database,
> regardless of whether it was sqlite or postgres. I think Go does a
> pretty good job of providing that thin layer of abstraction and it's up
> the driver writer to implement. After that what somebody wants to do
> with the results is their business.
>
> Personally I don't like ORM layers; most of the time I'm writing complex
> queries that don't fit neatly into an ORM paradigm and I end up fighting
> with the framework.
>
> Ron
>
> On 25 Oct 2016, at 15:44, Helge Heß via swift-server-dev wrote:
>
> > Hi,
> >
> > On 25 Oct 2016, at 21:34, Haris Amin <aminharis7 at gmail.com> wrote:
> >> So I’m currently working on a pure Swift Postgres driver.
> >
> > nice, I’m working on one as well (currently can run only basic
> > queries, nothing fancy).
> >
> >> 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.
> >
> > 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 ;-)
> >
> > For making the Unix calls a little nicer Swift extensions on the Unix
> > types are IMO pretty awesome, something along those lines:
> >
> >
> https://github.com/NozeIO/Noze.io/blob/master/Sources/net/SocketAddress.swift
> >
> > I would avoid creating wrappers which are then just wrapped again by
> > the higher level frameworks …
> >
> > 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.
> >
> >> 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?
> >
> > If it is part of Foundation you can assume it is supposed to work,
> > right? :-)
> >
> >> 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.
> >
> > +1 (And that should probably be part of Foundation as it is required
> > just the same on the client side).
> >
> >> 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.
> >
> > 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.
> >
> > 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).
> >
> >> My hope is we can start writing some of the drivers in pure Swift and
> >> help all those frameworks/libs get better too.
> >
> > 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.
> >
> > Anywayz, interesting to see what people come up with :-)
> >
> > hh
> >
> > _______________________________________________
> > swift-server-dev mailing list
> > swift-server-dev at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-server-dev
>
>
> ------------------------------
>
> Message: 10
> Date: Wed, 26 Oct 2016 00:00:35 +0200
> From: Alex Blewitt <alblue at apple.com>
> To: frogcjn at 163.com
> Cc: swift-server-dev <swift-server-dev at swift.org>
> Subject: Re: [swift-server-dev] [Bug] Foundation.URL should support
> semicolon(; ) appearing in URL path
> Message-ID: <3A980DA0-E213-4DBE-B928-C36094446C00 at apple.com>
> Content-Type: text/plain; charset=utf-8
>
>
>
> > On 25 Oct 2016, at 21:09, Cao, Jiannan via swift-server-dev <
> swift-server-dev at swift.org> wrote:
> >
> >
> > http://host/book;id=1/page;2/
> >
> > this URL is a valid URL, but URLComponents will ruin it with %3B
> > http://host/book%3Bid=1/page%3B2/
> >
> > Since Swift Server is coming out, this bug should be solved.
>
> Can you report this on https://bugs.swift.org so that it's tracked
> appropriately?
>
> Thanks,
>
> Alex
>
> Sent from my iPhone 📱
>
>
> ------------------------------
>
> Message: 11
> Date: Tue, 25 Oct 2016 16:11:55 -0700
> From: Rick Mann <rmann at latencyzero.com>
> To: swift-server-dev at swift.org
> Subject: [swift-server-dev] Spring and Baratine (Java frameworks)
> Message-ID: <1736F138-7246-460C-9CC2-781446A1C90F at latencyzero.com>
> Content-Type: text/plain; charset=us-ascii
>
> Hi all,
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> Hopefully I'm being overly pessimistic, and we're able to enjoy elegant,
> powerful, scalable web development in the near future.
>
> In any case, I hope I can make a positive contribution.
>
> --
> Rick Mann
> rmann at latencyzero.com
>
> *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.
>
> ------------------------------
>
> Message: 12
> Date: Tue, 25 Oct 2016 17:30:31 -0700
> From: Tyler Cloutier <cloutiertyler at aol.com>
> To: swift-server-dev at swift.org
> Subject: [swift-server-dev] Lib dispatch and Edge
> Message-ID: <56052D8D-8D9D-43E9-B9BF-0A77A09B04D2 at aol.com>
> Content-Type: text/plain; charset=utf-8
>
> Hello everyone!
>
> 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. https://github.com/SwiftOnEdge/Edge
>
> 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.
>
> Thank you,
>
> Tyler
>
> ------------------------------
>
> Message: 13
> Date: Wed, 26 Oct 2016 10:00:59 +0100
> From: Yoann Gini <yoann.gini at gmail.com>
> To: swift-server-dev at swift.org
> Subject: [swift-server-dev] Why not rely on existing models?
> Message-ID: <E3E74862-0681-43F3-B526-B75DD3BE497F at gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi
>
> 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.
>
> Swift look like a perfect language for server side, especially with Cocoa
> framework on the back.
>
> Looking at all the current initiative, I’ve to say don’t understand
> something: why everyone start by creating a brand new HTTP server?
>
> 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.
>
> 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.
>
> Looking at what currently exists, I found WSGI (or even old school CGI)
> way more interesting for production purpose.
>
> 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.
>
> This is just a simple personal opinion. Just wondering why.
>
> Best regards,
> Yoann Gini
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.swift.org/pipermail/swift-server-dev/attachments/20161026/8124b46d/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 14
> Date: Wed, 26 Oct 2016 11:25:16 +0200
> From: Helge Heß <me at helgehess.eu>
> To: Paulo Faria via swift-server-dev <swift-server-dev at swift.org>
> Subject: Re: [swift-server-dev] Why not rely on existing models?
> Message-ID: <8296A4EE-B0C1-449D-8F64-3C50231CB0F9 at helgehess.eu>
> Content-Type: text/plain; charset=us-ascii
>
> Is there a need for a swift-server-users mailing list?
>
> hh
>
>
>
> ------------------------------
>
> Message: 15
> Date: Wed, 26 Oct 2016 02:34:10 -0700
> From: Brent Royal-Gordon <brent at architechies.com>
> To: swift-server-dev at swift.org
> Subject: [swift-server-dev] Re: Database API/Framework
> Message-ID: <1FED5955-F653-4D36-8C82-986695A01CBE at architechies.com>
> Content-Type: text/plain; charset=utf-8
>
> (Sorry for the fake threading; I read this thread in the web archive and
> wanted to chime in.)
>
> Helge Heß:
>
> > > 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.
> >
> >
> > 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.
> >
> > 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).
> >
> > > My hope is we can start writing some of the drivers in pure Swift and
> help all those frameworks/libs get better too.
> >
> >
> > 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.
>
> 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.)
>
> Drivers Interface Extension/Client
> DBD::MySQL -+ +- DBIx::Class
> DBD::PG -+----- DBI ----- +- DBIx::DataModel
> DBD::Oracle -+ +- Direct use
>
> 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.
>
> 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:
>
> let userID = …
> for row in try connection.query("SELECT * FROM posts WHERE user_id
> = \(userID)") {
> // `query`'s parameter is actually a `SQLStatement`, so
> the string literal is actually a SQL statement literal.
> …
> }
>
> 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:
>
> let userID = …
> let sortColumnName = …
> let ascending = …
>
> let postsTable = try! SQLTable("posts", in: connection)
> let sortColumn = try SQLColumn(named: sortColumnName, in:
> postsTable)
> let sortDirection: SQLFragment = ascending ? "ASC" : "DESC"
>
> for row in try connection.query("SELECT * FROM \(postsTable) WHERE
> user_id = \(userID) ORDER BY \(sortColumn) \(sortDirection)") {
> // In the above, the SQLTable, SQLColumn, and
> SQLStatementFragment are inserted without escaping,
> // while the non-database-specific userID is passed as a
> parameter.
> …
> }
>
> 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.
>
> 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.
>
> --
> Brent Royal-Gordon
> Architechies
>
>
>
> ------------------------------
>
> Message: 16
> Date: Wed, 26 Oct 2016 10:43:07 +0100
> From: Yoann Gini <yoann.gini at gmail.com>
> To: Helge Heß <me at helgehess.eu>
> Cc: Paulo Faria via swift-server-dev <swift-server-dev at swift.org>
> Subject: Re: [swift-server-dev] Why not rely on existing models?
> Message-ID: <D85F7505-334D-43D0-91BF-2183416636E2 at gmail.com>
> Content-Type: text/plain; charset=utf-8
>
>
> > Le 26 oct. 2016 à 10:25, Helge Heß via swift-server-dev <
> swift-server-dev at swift.org> a écrit :
> >
> > Is there a need for a swift-server-users mailing list?
>
> 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.
>
> 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.
>
> Best regards,
> Yoann Gini
>
>
>
> ------------------------------
>
> Message: 17
> Date: Wed, 26 Oct 2016 02:59:23 -0700
> From: Brent Royal-Gordon <brent at architechies.com>
> To: Yoann Gini <yoann.gini at gmail.com>
> Cc: swift-server-dev at swift.org
> Subject: Re: [swift-server-dev] Why not rely on existing models?
> Message-ID: <ABF1424E-6E00-4E3D-B68A-82A590D74143 at architechies.com>
> Content-Type: text/plain; charset=utf-8
>
> > On Oct 26, 2016, at 2:00 AM, Yoann Gini via swift-server-dev <
> swift-server-dev at swift.org> wrote:
> >
> > Looking at all the current initiative, I’ve to say don’t understand
> something: why everyone start by creating a brand new HTTP server?
> >
> > 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.
> >
> > 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.
>
> This trend seems to have started with Rails. It has a few advantages:
>
> 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.
>
> 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.
>
> 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.
>
> Basically, embedding a web server and reverse proxying for it isolates the
> application from the frontend server and simplifies the management of both.
>
> --
> Brent Royal-Gordon
> Architechies
>
>
>
> ------------------------------
>
> Message: 18
> Date: Wed, 26 Oct 2016 12:26:51 +0200
> From: Helge Heß <me at helgehess.eu>
> To: Paulo Faria via swift-server-dev <swift-server-dev at swift.org>
> Subject: Re: [swift-server-dev] Database API/Framework
> Message-ID: <D7AB25BE-3BAF-4C9B-A2C4-2B0A6243A93F at helgehess.eu>
> Content-Type: text/plain; charset=utf-8
>
> On 26 Oct 2016, at 11:34, Brent Royal-Gordon via swift-server-dev <
> swift-server-dev at swift.org> wrote:
> > 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.
>
> 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.
>
> 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).
> 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.
> Presumably a HL framework has to have specific support to account for
> dealing with such differences, it can’t just rely on ‘JDBC'.
>
> 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]).
>
>
> But I’m quite interested to see what proposals are coming in :-)
>
> hh
>
>
>
> ------------------------------
>
> Message: 19
> Date: Wed, 26 Oct 2016 11:33:43 +0100
> From: Yoann Gini <yoann.gini at gmail.com>
> To: Brent Royal-Gordon <brent at architechies.com>
> Cc: swift-server-dev at swift.org
> Subject: Re: [swift-server-dev] Why not rely on existing models?
> Message-ID: <7D95AB95-528E-43AC-9594-4E4A2A603E6F at gmail.com>
> Content-Type: text/plain; charset=utf-8
>
>
> > Le 26 oct. 2016 à 10:59, Brent Royal-Gordon <brent at architechies.com> a
> écrit :
> >
> > This trend seems to have started with Rails. It has a few advantages:
> >
> > 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.
>
> 100% agree with that
>
> > 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.
> >
> > 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.
> >
> > Basically, embedding a web server and reverse proxying for it isolates
> the application from the frontend server and simplifies the management of
> both.
>
> 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.
>
> In some scenario, this is better, in some others, this is worst.
>
> 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.
>
> Allowing behavior like WSGI where you can use both scenario is IMHO the
> best solution ever, so it can fit for all needs.
>
> Best regards,
> Yoann Gini
>
>
>
> ------------------------------
>
> Message: 20
> Date: Wed, 26 Oct 2016 12:39:01 +0100
> From: Chris Bailey <BAILEYC at uk.ibm.com>
> To: Helge Heß <me at helgehess.eu>
> Cc: swift-server-dev at swift.org
> Subject: Re: [swift-server-dev] Database API/Framework
> Message-ID:
> <
> OF4B342709.861A5D1A-ON80258058.00369FEC-80258058.003FFEF3 at notes.na.collabserv.com
> >
>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Helge:
>
> As the initial target areas are low-level function, yes, each of the
> frameworks has an implementation of most of them today. Those
> implementations tend to be limited in a number of ways:
> C libraries are often used directly (via a modulemap)
> This means that there's no general "Swift API" that developers can use -
> you have to interface with the C APIs directly and deal with
> Unsafe/OpaquePointers etc. Ideally we want Swift developers to only have
> to write Swift code
> Where a Swift API wraps a C library its generally for a specific use case
> As the framework teams have a very specific use case - using it in their
> framework - the APIs are very directed to what they need to do, rather
> than being general purpose for a wider set of use cases
> There's multiple, similar, packages
> Most frameworks have their own server socket implementation (mostly by
> calling Glibc and Darwin), HTTP parser implementation, etc. Not only does
> this mean we can consolidate the efforts on a single implementation, but
> it means that anyone wanting to add additional platform support (like
> Windows) only has to do so once.
>
> Chris
>
>
>
>
> From: Helge Heß via swift-server-dev <swift-server-dev at swift.org>
> To: swift-server-dev at swift.org
> Date: 25/10/2016 19:57
> Subject: Re: [swift-server-dev] Database API/Framework
> Sent by: swift-server-dev-bounces at swift.org
>
>
>
> Hi Chris,
>
> it is a little unclear what the scope of the group is. Presumably you have
> some very specific things in mind?
>
> Of course we’ve seen https://swift.org/server-apis/#focus-areas. But what
> does it actually mean? :-) Looking at it:
> - base networking: TCP/UDP, DNS. Covered already by libdispatch and the
> OS’ses?
> - security: OpenSSL? or some wrapper around both, CC and OpenSSL?
> - provide low level HTTP parsing: http_parser? Is anyone using something
> else?
> All that seems kinda covered/standard already? Unless maybe you include
> non-Unix stuff like Windows.
>
> Is this primarily for things like providing a standardised ’swiftier'
> OpenSSL wrapper (similar to how Objective-GCD wraps libdispatch)?
> Or would that just be module maps which are shipped by default with Swift
> and hence can be relied on by all frameworks?
>
> But maybe I’m just a little too impatient :->
>
> hh
>
> > On 25 Oct 2016, at 20:41, Chris Bailey via swift-server-dev
> <swift-server-dev at swift.org> wrote:
> >
> > Hi Ron:
> >
> > As you say, that's outside of the scope of the work group, however I do
> think its a valuable area that the various existing web framework groups
> might be interested in collaborating on. Having a common, recognized
> framework that the database providers or third parties would be interested
> in writing database drivers for would be a huge step forward.
> >
> > I know that Vapor has its Fluent ORM framework, and that its an area
> that the Kitura team are looking at as well, so your post might kick-start
> some wider discussion.
> >
> > Chris
> >
> >
> >
> >
> > From: Ron Olson via swift-server-dev <swift-server-dev at swift.org>
>
> > To: swift-server-dev at swift.org
> > Date: 25/10/2016 18:54
> > Subject: [swift-server-dev] Database API/Framework
> > Sent by: swift-server-dev-bounces at swift.org
> >
> >
> >
> > Hi all-
> >
> > I've been working with Swift more on Linux than macOS and am very
> > excited to see the formation of this group. Looking at the server api
> > workgroup's focus, I notice it's primarily low-level interaction with
> > the operating system. When might it be a good time to bring up the
> > possibility of creating a database-specific framework for those folks
> > who want to work directly with Postgres, MySQL, even DB2 and Oracle; I'm
>
> > thinking a JDBC-inspired framework that drivers could be written
> > against.
> >
> > Thanks,
> >
> > Ron
> > _______________________________________________
> > swift-server-dev mailing list
> > swift-server-dev at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-server-dev
> >
> >
> > _______________________________________________
> > swift-server-dev mailing list
> > swift-server-dev at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-server-dev
>
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-server-dev
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.swift.org/pipermail/swift-server-dev/attachments/20161026/f87a0fbc/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 21
> Date: Wed, 26 Oct 2016 14:35:03 +0100
> From: Gregor Milos <gmilos at apple.com>
> To: Chris Bailey <BAILEYC at uk.ibm.com>
> Cc: swift-server-dev at swift.org
> Subject: Re: [swift-server-dev] Database API/Framework
> Message-ID: <C2BA24EC-223C-4518-AD1E-057EB1585FAC at apple.com>
> Content-Type: text/plain; charset=utf-8
>
> Helge,
>
> 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:
> * Go comes with https://golang.org/pkg/net/http/
> * Netty (defacto standard Java net lib) comes with:
> http://netty.io/4.1/api/io/netty/handler/codec/http/package-frame.html
> * etc ...
> 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.
>
> Thanks
> Gregor
>
>
> > On 26 Oct 2016, at 12:39, Chris Bailey via swift-server-dev <
> swift-server-dev at swift.org> wrote:
> >
> > Hi Helge:
> >
> > As the initial target areas are low-level function, yes, each of the
> frameworks has an implementation of most of them today. Those
> implementations tend to be limited in a number of ways:
> > • C libraries are often used directly (via a modulemap)
> > This means that there's no general "Swift API" that developers can use -
> you have to interface with the C APIs directly and deal with
> Unsafe/OpaquePointers etc. Ideally we want Swift developers to only have to
> write Swift code
> > • Where a Swift API wraps a C library its generally for a specific
> use case
> > As the framework teams have a very specific use case - using it in their
> framework - the APIs are very directed to what they need to do, rather than
> being general purpose for a wider set of use cases
> > • There's multiple, similar, packages
> > Most frameworks have their own server socket implementation (mostly by
> calling Glibc and Darwin), HTTP parser implementation, etc. Not only does
> this mean we can consolidate the efforts on a single implementation, but it
> means that anyone wanting to add additional platform support (like Windows)
> only has to do so once.
> >
> > Chris
> >
> >
> >
> >
> > From: Helge Heß via swift-server-dev <swift-server-dev at swift.org>
> > To: swift-server-dev at swift.org
> > Date: 25/10/2016 19:57
> > Subject: Re: [swift-server-dev] Database API/Framework
> > Sent by: swift-server-dev-bounces at swift.org
> >
> >
> >
> > Hi Chris,
> >
> > it is a little unclear what the scope of the group is. Presumably you
> have some very specific things in mind?
> >
> > Of course we’ve seen https://swift.org/server-apis/#focus-areas. But
> what does it actually mean? :-) Looking at it:
> > - base networking: TCP/UDP, DNS. Covered already by libdispatch and the
> OS’ses?
> > - security: OpenSSL? or some wrapper around both, CC and OpenSSL?
> > - provide low level HTTP parsing: http_parser? Is anyone using something
> > else?
> > All that seems kinda covered/standard already? Unless maybe you include
> non-Unix stuff like Windows.
> >
> > Is this primarily for things like providing a standardised ’swiftier'
> OpenSSL wrapper (similar to how Objective-GCD wraps libdispatch)?
> > Or would that just be module maps which are shipped by default with
> Swift and hence can be relied on by all frameworks?
> >
> > But maybe I’m just a little too impatient :->
> >
> > hh
> >
> > > On 25 Oct 2016, at 20:41, Chris Bailey via swift-server-dev <
> swift-server-dev at swift.org> wrote:
> > >
> > > Hi Ron:
> > >
> > > As you say, that's outside of the scope of the work group, however I
> do think its a valuable area that the various existing web framework groups
> might be interested in collaborating on. Having a common, recognized
> framework that the database providers or third parties would be interested
> in writing database drivers for would be a huge step forward.
> > >
> > > I know that Vapor has its Fluent ORM framework, and that its an area
> that the Kitura team are looking at as well, so your post might kick-start
> some wider discussion.
> > >
> > > Chris
> > >
> > >
> > >
> > >
> > > From: Ron Olson via swift-server-dev <
> swift-server-dev at swift.org>
> > > To: swift-server-dev at swift.org
> > > Date: 25/10/2016 18:54
> > > Subject: [swift-server-dev] Database API/Framework
> > > Sent by: swift-server-dev-bounces at swift.org
> > >
> > >
> > >
> > > Hi all-
> > >
> > > I've been working with Swift more on Linux than macOS and am very
> > > excited to see the formation of this group. Looking at the server api
> > > workgroup's focus, I notice it's primarily low-level interaction with
> > > the operating system. When might it be a good time to bring up the
> > > possibility of creating a database-specific framework for those folks
> > > who want to work directly with Postgres, MySQL, even DB2 and Oracle;
> I'm
> > > thinking a JDBC-inspired framework that drivers could be written
> > > against.
> > >
> > > Thanks,
> > >
> > > Ron
> > > _______________________________________________
> > > swift-server-dev mailing list
> > > swift-server-dev at swift.org
> > > https://lists.swift.org/mailman/listinfo/swift-server-dev
> > >
> > >
> > > _______________________________________________
> > > swift-server-dev mailing list
> > > swift-server-dev at swift.org
> > > https://lists.swift.org/mailman/listinfo/swift-server-dev
> >
> > _______________________________________________
> > swift-server-dev mailing list
> > swift-server-dev at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-server-dev
> >
> >
> > _______________________________________________
> > swift-server-dev mailing list
> > swift-server-dev at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-server-dev
>
>
>
> ------------------------------
>
> Message: 22
> Date: Wed, 26 Oct 2016 14:41:00 +0100
> From: Gregor Milos <gmilos at apple.com>
> To: Gregor Milos <gmilos at apple.com>
> Cc: swift-server-dev at swift.org
> Subject: Re: [swift-server-dev] Database API/Framework
> Message-ID: <A338CA7D-6E7E-4D1E-B10C-C81764DDD909 at apple.com>
> Content-Type: text/plain; CHARSET=US-ASCII
>
>
> > On 26 Oct 2016, at 14:35, Gregor Milos via swift-server-dev <
> swift-server-dev at swift.org> wrote:
> >
> > Expand
> s/Expand/Expanding/
>
>
>
> ------------------------------
>
> Message: 23
> Date: Wed, 26 Oct 2016 16:39:20 +0200
> From: Helge Heß <me at helgehess.eu>
> To: Paulo Faria via swift-server-dev <swift-server-dev at swift.org>
> Subject: Re: [swift-server-dev] Database API/Framework
> Message-ID: <C7A408BB-7EAC-4573-A01F-343588116F77 at helgehess.eu>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Gregor,
>
> On 26 Oct 2016, at 15:35, Gregor Milos <gmilos at apple.com> wrote:
> > Expand on Chris's answer, modern languages used on server side come with
> abstractions native to their language.
>
> now that is a pretty bold claim. C, C++, Java, JavaScript, Ruby and
> Objective-C, don’t. Python does, but few use that. But yes, Go seems to
> come with one … :-)
>
> > * Netty (defacto standard Java net lib)
>
> Hu?! Since when is Netty the `defacto standard Java net lib`? Netty is a
> prime example of just being one of many options coming as a 3rd party
> package (being a good one for sure).
>
>
> OK OK, nitpicking aside, so the goal this:
>
> > Our task should be to design an API that works well in Swift.
>
> Understood. So the plan is indeed to replace the kernel of the HL
> frameworks with a common Swift `http` server module. A peer to
> https://golang.org/pkg/net/http/. Fair enough.
>
>
> > Node's http_parser is "just" an example of an API and a possible way of
> accelerating the implementation of Swift's HTTP parser.
>
> The http_parser is not just 'an example of an API', it is an actual
> implementation of a HTTP parser which can be used from Swift right away.
> And not a bad one :-) I guess my original question was why people invent
> their own instead of just using the implementations directly accessible
> already. Same for OpenSSL, Expat, etc. I really like the Swift-C mapping
> and how convenient it is to use.
>
> Unless of course we are not talking about providing core support for HL
> frameworks (which provide the nice API of their choice to backend
> developers), but for directly providing nice APIs to backend developers as
> part of the Swift project. (so that they don’t have to grab say Kitura just
> to build a small micro service).
>
>
> But I think I got you, you want to wrap that kind of thing (or rewrite in
> pure Swift) in a nicer, Swiftier API. Thanks for clarifying that.
>
> hh
>
>
> >> On 26 Oct 2016, at 12:39, Chris Bailey via swift-server-dev <
> swift-server-dev at swift.org> wrote:
> >>
> >> Hi Helge:
> >>
> >> As the initial target areas are low-level function, yes, each of the
> frameworks has an implementation of most of them today. Those
> implementations tend to be limited in a number of ways:
> >> • C libraries are often used directly (via a modulemap)
> >> This means that there's no general "Swift API" that developers can use
> - you have to interface with the C APIs directly and deal with
> Unsafe/OpaquePointers etc. Ideally we want Swift developers to only have to
> write Swift code
> >> • Where a Swift API wraps a C library its generally for a specific
> use case
> >> As the framework teams have a very specific use case - using it in
> their framework - the APIs are very directed to what they need to do,
> rather than being general purpose for a wider set of use cases
> >> • There's multiple, similar, packages
> >> Most frameworks have their own server socket implementation (mostly by
> calling Glibc and Darwin), HTTP parser implementation, etc. Not only does
> this mean we can consolidate the efforts on a single implementation, but it
> means that anyone wanting to add additional platform support (like Windows)
> only has to do so once.
> >>
> >> Chris
> >>
> >>
> >>
> >>
> >> From: Helge Heß via swift-server-dev <swift-server-dev at swift.org
> >
> >> To: swift-server-dev at swift.org
> >> Date: 25/10/2016 19:57
> >> Subject: Re: [swift-server-dev] Database API/Framework
> >> Sent by: swift-server-dev-bounces at swift.org
> >>
> >>
> >>
> >> Hi Chris,
> >>
> >> it is a little unclear what the scope of the group is. Presumably you
> have some very specific things in mind?
> >>
> >> Of course we’ve seen https://swift.org/server-apis/#focus-areas. But
> what does it actually mean? :-) Looking at it:
> >> - base networking: TCP/UDP, DNS. Covered already by libdispatch and the
> OS’ses?
> >> - security: OpenSSL? or some wrapper around both, CC and OpenSSL?
> >> - provide low level HTTP parsing: http_parser? Is anyone using something
> >> else?
> >> All that seems kinda covered/standard already? Unless maybe you include
> non-Unix stuff like Windows.
> >>
> >> Is this primarily for things like providing a standardised ’swiftier'
> OpenSSL wrapper (similar to how Objective-GCD wraps libdispatch)?
> >> Or would that just be module maps which are shipped by default with
> Swift and hence can be relied on by all frameworks?
> >>
> >> But maybe I’m just a little too impatient :->
> >>
> >> hh
> >>
> >>> On 25 Oct 2016, at 20:41, Chris Bailey via swift-server-dev <
> swift-server-dev at swift.org> wrote:
> >>>
> >>> Hi Ron:
> >>>
> >>> As you say, that's outside of the scope of the work group, however I
> do think its a valuable area that the various existing web framework groups
> might be interested in collaborating on. Having a common, recognized
> framework that the database providers or third parties would be interested
> in writing database drivers for would be a huge step forward.
> >>>
> >>> I know that Vapor has its Fluent ORM framework, and that its an area
> that the Kitura team are looking at as well, so your post might kick-start
> some wider discussion.
> >>>
> >>> Chris
> >>>
> >>>
> >>>
> >>>
> >>> From: Ron Olson via swift-server-dev <
> swift-server-dev at swift.org>
> >>> To: swift-server-dev at swift.org
> >>> Date: 25/10/2016 18:54
> >>> Subject: [swift-server-dev] Database API/Framework
> >>> Sent by: swift-server-dev-bounces at swift.org
> >>>
> >>>
> >>>
> >>> Hi all-
> >>>
> >>> I've been working with Swift more on Linux than macOS and am very
> >>> excited to see the formation of this group. Looking at the server api
> >>> workgroup's focus, I notice it's primarily low-level interaction with
> >>> the operating system. When might it be a good time to bring up the
> >>> possibility of creating a database-specific framework for those folks
> >>> who want to work directly with Postgres, MySQL, even DB2 and Oracle;
> I'm
> >>> thinking a JDBC-inspired framework that drivers could be written
> >>> against.
> >>>
> >>> Thanks,
> >>>
> >>> Ron
> >>> _______________________________________________
> >>> swift-server-dev mailing list
> >>> swift-server-dev at swift.org
> >>> https://lists.swift.org/mailman/listinfo/swift-server-dev
> >>>
> >>>
> >>> _______________________________________________
> >>> swift-server-dev mailing list
> >>> swift-server-dev at swift.org
> >>> https://lists.swift.org/mailman/listinfo/swift-server-dev
> >>
> >> _______________________________________________
> >> swift-server-dev mailing list
> >> swift-server-dev at swift.org
> >> https://lists.swift.org/mailman/listinfo/swift-server-dev
> >>
> >>
> >> _______________________________________________
> >> swift-server-dev mailing list
> >> swift-server-dev at swift.org
> >> https://lists.swift.org/mailman/listinfo/swift-server-dev
> >
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 842 bytes
> Desc: Message signed with OpenPGP using GPGMail
> URL: <
> https://lists.swift.org/pipermail/swift-server-dev/attachments/20161026/edc8b416/attachment-0001.sig
> >
>
> ------------------------------
>
> Message: 24
> Date: Wed, 26 Oct 2016 16:52:42 +0200
> From: Benedikt Terhechte <terhechte at me.com>
> To: swift-server-dev at swift.org
> Subject: [swift-server-dev] Async I/O in Rust Tokio
> Message-ID: <F8F240BF-A133-4D1B-A1CA-08B1457E591F at me.com>
> Content-Type: text/plain; charset=utf-8
>
> Hey,
>
> 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.
>
> 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:
>
> "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.”
>
> https://github.com/tokio-rs/tokio
>
> 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.
>
> 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.
>
> Cheers,
> Benedikt
>
> ------------------------------
>
> Message: 25
> Date: Wed, 26 Oct 2016 16:31:34 +0100
> From: Gregor Milos <gmilos at apple.com>
> To: Helge Heß <me at helgehess.eu>
> Cc: Paulo Faria via swift-server-dev <swift-server-dev at swift.org>
> Subject: Re: [swift-server-dev] Database API/Framework
> Message-ID: <D7BE19C8-9169-4B5A-95E2-55B19E927BA0 at apple.com>
> Content-Type: text/plain; charset=utf-8
>
> Additional advantage of a standardised APIs+implementation is standardised
> license. MIT (for NGINX http_parser) is not a big deal, but the more
> dependencies you're pulling into your app, the harder it's to track it all.
>
>
> Some more comments inline:
>
> > On 26 Oct 2016, at 15:39, Helge Heß via swift-server-dev <
> swift-server-dev at swift.org> wrote:
> >
> > Hi Gregor,
> >
> > On 26 Oct 2016, at 15:35, Gregor Milos <gmilos at apple.com> wrote:
> >> Expand on Chris's answer, modern languages used on server side come
> with abstractions native to their language.
> >
> > now that is a pretty bold claim. C, C++, Java, JavaScript, Ruby and
> Objective-C, don’t. Python does, but few use that. But yes, Go seems to
> come with one … :-)
> >
> >> * Netty (defacto standard Java net lib)
> >
> > Hu?! Since when is Netty the `defacto standard Java net lib`? Netty is a
> prime example of just being one of many options coming as a 3rd party
> package (being a good one for sure).
>
> It's all about the definition of "modern" ;). More seriously though, the
> core of my point is that good APIs are invariably designed for the language
> in question, rather than foreign imports. The distribution model
> (compiler/stdlib/common libraries/package manager) is orthogonal. At this
> point I don't think it's clear how we are going to deliver the
> implementation of APIs designed by this work-group either.
> https://swift.org/server-apis/ talks about the process somewhat, but
> where the code belongs will largely depend on what it evolves to look like.
>
> >
> >
> > OK OK, nitpicking aside, so the goal this:
> >
> >> Our task should be to design an API that works well in Swift.
> >
> > Understood. So the plan is indeed to replace the kernel of the HL
> frameworks with a common Swift `http` server module. A peer to
> https://golang.org/pkg/net/http/. Fair enough.
> >
> >
> >> Node's http_parser is "just" an example of an API and a possible way of
> accelerating the implementation of Swift's HTTP parser.
> >
> > The http_parser is not just 'an example of an API', it is an actual
> implementation of a HTTP parser which can be used from Swift right away.
> And not a bad one :-) I guess my original question was why people invent
> their own instead of just using the implementations directly accessible
> already. Same for OpenSSL, Expat, etc. I really like the Swift-C mapping
> and how convenient it is to use.
>
> Yes, it can be used from Swift and yes, it's a good parser. But the fact
> it's not a Swift HTTP parser is immediately obvious. We always wrap it in
> layer of Swift that deals with all the UnsafeMutablePointers, state
> management and something that exposes API conforming to
> https://swift.org/documentation/api-design-guidelines/.
>
> Hope this all makes sense.
> Gregor
>
> >
> > Unless of course we are not talking about providing core support for HL
> frameworks (which provide the nice API of their choice to backend
> developers), but for directly providing nice APIs to backend developers as
> part of the Swift project. (so that they don’t have to grab say Kitura just
> to build a small micro service).
> >
> >
> > But I think I got you, you want to wrap that kind of thing (or rewrite
> in pure Swift) in a nicer, Swiftier API. Thanks for clarifying that.
> >
> > hh
> >
> >
> >>> On 26 Oct 2016, at 12:39, Chris Bailey via swift-server-dev <
> swift-server-dev at swift.org> wrote:
> >>>
> >>> Hi Helge:
> >>>
> >>> As the initial target areas are low-level function, yes, each of the
> frameworks has an implementation of most of them today. Those
> implementations tend to be limited in a number of ways:
> >>> • C libraries are often used directly (via a modulemap)
> >>> This means that there's no general "Swift API" that developers can use
> - you have to interface with the C APIs directly and deal with
> Unsafe/OpaquePointers etc. Ideally we want Swift developers to only have to
> write Swift code
> >>> • Where a Swift API wraps a C library its generally for a specific
> use case
> >>> As the framework teams have a very specific use case - using it in
> their framework - the APIs ar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20161026/0a617882/attachment.html>
More information about the swift-server-dev
mailing list