[
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)
