Hi,
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
···
On 25 Oct 2016, at 21:34, Haris Amin <aminharis7@gmail.com> wrote:
