[jira] [Comment Edited] (THRIFT-3773) Swift Library

["Chris Simpson (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/THRIFT-3773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15439489#comment-15439489 ] 

Chris Simpson edited comment on THRIFT-3773 at 8/26/16 6:13 PM:
----------------------------------------------------------------

I currently have everything I'm working on in a private repo unfortunately, I'll push updates to my public fork of Thrift soon.
Currently its changing quickly due to Swift 3.0 being finalized, there still isn't 1:1 parity on API's so I have some extensions filling in the gaps, as well as some things are still unimplemented (Like URLSession :/).
Good news is I've tested out Binary/Compact protocols on both OSX and Linux and they work great, THTTP/SessionTransport work great on OSX (again still unimplemented in linux :/ ), and TSocketTransport works on both platforms. I renamed the existing Cocoa TSocketTransport implementation that I converted to swift to TCFSocketTransport and created a separate TSocketTransport leveraging posix sockets since Input/OutputStreams are still not 100% complete in Linux (However once they're done we can get rid of the more raw CF stuff since InputStream will have getStreamsToHost()).
Also contemplated making a GCD based async socket but couldn't get it to work properly so temporarily shelved that idea.

One thing i'm having issue with is serialization from other languages.  I decided that Structs shouldn't have an empty init() case and that non-optional vars shouldn't be initialized with empty types (i.e. no var userID = Int32()), but that presents compatibility problems with other languages (python specifically) where empty structs can be created and written with NULL values for required fields that weren't set.  In reality this shouldn't be an issue as properly designed interfaces will ensure the server is populating any/all required fields, but I may throw in a strict option to default use empty initialization and not use it when strict is set (this creates a cleaner Swift-ier interface).

Other things I've not yet tested or implemented are server implementations, however thats what's on my plate now ;).  TSocketServer should work fine (it compiles and everything needed is implemented in Linux), and I've decided not to write an HTTPServer implementation since there's too much overhead to throw into the library and not an existing one within the standard library (and the goal is to not have any dependancies).  I may show an example of how to use a 3rd party HTTPServer as a thrift HTTP Server however which would fulfill most needs for that, there are several competing Swift HTTP Server implementations already, and in the near future there are sure to be some even better performing ones now that GCD is available on Linux properly.

A few more thing I need to shore up and test are async clients, and default values for the code generator, as well as I'd like to try to do something for namespacing.  My current plan for namespacing is to have the generator dump generated source in subdirectories per-namespace such that they can be imported as separate modules into whatever project (whether it be SPM or Xcode based), any thoughts on this are very welcome as I havent given it much thought but it's something that's definitely needed (Already ran into a namespace collision with some IDL's we use at work where we have an `Error` struct... Apple renamed Swift's ErrorType to ErrorProtocol and finally Error, so in the generator I actually explicitly specify Swift.Error for any exception types to avoid local namespace collisions, but that presents a problem if its not modularized)


was (Author: apocolipse):
I currently have everything I'm working on in a private repo unfortunately, I'll push updates to my public fork of Thrift soon.
Currently its changing quickly due to Swift 3.0 being finalized, there still isn't 1:1 parity on API's so I have some extensions filling in the gaps, as well as some things are still unimplemented (Like URLSession :/).
Good news is I've tested out Binary/Compact protocols on both OSX and Linux and they work great, THTTP/SessionTransport work great on OSX (again still unimplemented in linux :/ ), and TSocketTransport works on both platforms. I renamed the existing Cocoa TSocketTransport implementation that I converted to swift to TCFSocketTransport and created a separate TSocketTransport leveraging posix sockets since Input/OutputStreams are still not 100% complete in Linux (However once they're done we can get rid of direct stuff since InputStream will have getStreamsToHost()).
Also contemplated making a GCD based async socket but couldn't get it to work properly so temporarily shelved that idea.

One thing i'm having issue with is serialization from other languages.  I decided that Structs shouldn't have an empty init() case and that non-optional vars shouldn't be initialized with empty types (i.e. no var userID = Int32()), but that presents compatibility problems with other languages (python specifically) where empty structs can be created and written with NULL values for required fields that weren't set.  In reality this shouldn't be an issue as properly designed interfaces will ensure the server is populating any/all required fields, but I may throw in a strict option to default use empty initialization and not use it when strict is set (this creates a cleaner Swift-ier interface).

Other things I've not yet tested or implemented are server implementations, however thats what's on my plate now ;).  TSocketServer should work fine (it compiles and everything needed is implemented in Linux), and I've decided not to write an HTTPServer implementation since there's too much overhead to throw into the library and not an existing one within the standard library (and the goal is to not have any dependancies).  I may show an example of how to use a 3rd party HTTPServer as a thrift HTTP Server however which would fulfill most needs for that, there are several competing Swift HTTP Server implementations already, and in the near future there are sure to be some even better performing ones now that GCD is available on Linux properly.

A few more thing I need to shore up and test are async clients, and default values for the code generator, as well as I'd like to try to do something for namespacing.  My current plan for namespacing is to have the generator dump generated source in subdirectories per-namespace such that they can be imported as separate modules into whatever project (whether it be SPM or Xcode based), any thoughts on this are very welcome as I havent given it much thought but it's something that's definitely needed (Already ran into a namespace collision with some IDL's we use at work where we have an `Error` struct... Apple renamed Swift's ErrorType to ErrorProtocol and finally Error, so in the generator I actually explicitly specify Swift.Error for any exception types to avoid local namespace collisions, but that presents a problem if its not modularized)

> Swift Library
> -------------
>
>                 Key: THRIFT-3773
>                 URL: https://issues.apache.org/jira/browse/THRIFT-3773
>             Project: Thrift
>          Issue Type: New Feature
>          Components: Swift - Library
>            Reporter: Thomas Bartelmess
>
> We already have the option to generate Swift code in the Cocoa compiler, however large parts of the (Objective-C) Cocoa Library still depend on Cocoa and  Objective-C.
> It would be good to have a native Swift library that doesn't depend on the Cocoa libraries.
> Design goals:
> - Fully compatible with the code that is currently generated by the Cocoa compiler (both Objective-C and Swift).
> - Ability to run on Linux
> - Pure Swift, no Objective-C code.
> - No dependencies on closed source apple libraries
> - Keep the same interface, so that the library is compatible with the code the current cocoa compiler generates
> - Better server support that the current Objective-C library.
> - Follow the new Swift packaging format to be compatible with the Swift Package manager



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)