thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Wojniak <kwojn...@box.com.INVALID>
Subject Re: Objective-C support
Date Mon, 22 Apr 2019 14:41:35 GMT
Instead of bringing back the objc code and fully supporting it going
forward, what about releasing one or more 0.12 minor updates to fix a few
bugs in the objc code? I can make issues and PRs for the changes.

Kevin

On Mon, Apr 22, 2019 at 5:51 AM James E. King III <jking@apache.org> wrote:

> There should be no incompatibilities if both sides are using binary
> protocol, for example, since that format has been very stable.
> We haven't expressly done cross-version testing in our CI however the
> compatibility should work.
>
> We also need someone to write the TestClient and TestServer for swift
> so it can be part of our cross-language test suite.
>
> - Jim
>
> On Sun, Apr 21, 2019 at 7:55 PM Kevin Wojniak <kwojniak@box.com.invalid>
> wrote:
> >
> > Hi Jim,
> >
> > Sorry for the delay in responding. Other tasks have taken priority!
> >
> > Cocoa is Apple specific, but there is GNUstep, however that is not widely
> > used. I do notice the existing Swift port is still using the Cocoa
> > libraries, and seems to be a direct, although incomplete, port from the
> > Objective-C sources. The "Cocoa" version should be called Objective-C
> > (objc), if it ever is brought back, for clarity.
> >
> > One thing to note about the existing Swift implementation is still using
> > NSFileHandle in TSocketServer, which unfortunately handles read and write
> > errors by throwing Objective-C exceptions (since it's actually written in
> > Objective-C). However, Swift cannot natively catch Objective-C errors, so
> > the current code is broken, and on error with crash the process. One
> needs
> > to write a wrapper in Objective-C (easy enough in the bridging header)
> and
> > handle this in Swift. The 0.12 Objective-C actually misses a few of these
> > exceptions as well.
> >
> > While Swift can be used in Objective-C, one needs to use a subset of
> Swift
> > features publicly to properly interface with Obj-C, so unless there are
> > Objective-C tests for Swift, the Swift codebase will eventually (if not
> > already) become unusable in Objective-C.
> >
> > Our big concern, and it doesn't seem to be documented anywhere (unless I
> > missed it), is if it's safe to use (for example) Thrift 0.12 Python
> process
> > to talk to a Thrift 0.9 Objective-C process. We assumed this wouldn't be,
> > and didn't want to take any risks.
> >
> > Thanks,
> > Kevin
> >
> >
> > On Mon, Mar 25, 2019 at 5:38 AM James E. King III <jking@apache.org>
> wrote:
> >
> > > Hi,
> > >
> > > The consensus was that cocoa has been deprecated since 2012, nobody was
> > > actively
> > > pushing it forward, it was never integrated into the cross-language
> > > integration test suite,
> > > and the project has support for 28 languages and limited resources to
> > > do that.  Given the
> > > long deprecation time and various internet discussions, and that
> > > nobody spoke up on the
> > > developer mailing list.  This discussion happened only on the dev
> > > mailing list, which was
> > > clearly an error on my part.
> > >
> > > If there is significant community support and folks want to get
> > > involved in actively maintaining it,
> > > we can open a discussion about that.  We haven't released 0.13.0 yet
> > > so there isn't a release
> > > where it has been removed.  At the time, folks who actively work on
> > > the project agreed that
> > > OSX development future is Swift, and folks ought to be moving towards
> > > Swift.  You can
> > > continue to use 0.12.0 with cocoa support for your cocoa projects.  It
> > > will still be compatible
> > > with future thrift releases.
> > >
> > > Is there a way to run cocoa on linux?  If so, integrating it and swift
> > > into the cross-language
> > > test framework is one of the top priorities to ensuring language
> > > support stays alive.
> > >
> > > Those are the reasons why it happened.
> > >
> > > Thanks,
> > >
> > > Jim (PMC Member)
> > >
> > >
> > > On Sat, Mar 23, 2019 at 2:25 PM Edward Capriolo <edlinuxguru@gmail.com
> >
> > > wrote:
> > > >
> > > > In general doesn't objective-c have a wider scope then swift anyway.
> Like
> > > > swift is targeted for mac but you can compile objective-c with gcc
> on any
> > > > nix?
> > > >
> > > > On Friday, March 22, 2019, Steve Yegge <steve.yegge@gmail.com>
> wrote:
> > > >
> > > > > I'd like to second this.  I have a large Objective-C app that
> won't be
> > > > > ported to Swift in the next few years.
> > > > >
> > > > >
> > > > > On Fri, Mar 22, 2019 at 1:54 PM Kevin Wojniak
> <kwojniak@box.com.invalid
> > > >
> > > > > wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I am curious as to why the Objective-C implementation was
> removed,
> > > since
> > > > > > Objective-C is not a deprecated language. The documentation
says
> to
> > > use
> > > > > > Swift. However, Swift is not fully backwards compatible with
> > > Objective-C.
> > > > > > Also, bringing in Swift to Objective-C means bringing in the
> entire
> > > Swift
> > > > > > runtime, which is not always desired.
> > > > > >
> > > > > > I noticed the Objective-C implementation of Thrift was upgraded
> to
> > > modern
> > > > > > syntax which significantly improves the usage in Swift. This
> system
> > > works
> > > > > > well for both Objective-C and Swift clients.
> > > > > >
> > > > > > We still use Thrift with Swift and Objective-C code bases and
> don't
> > > have
> > > > > > plans on porting Objective-C to Swift. However we do need to
> upgrade
> > > our
> > > > > > Python usage of Thrift, which is why we're looking at upgrading
> our
> > > > > Thrift
> > > > > > usage across multiple languages (C# and C++).
> > > > > >
> > > > > > Are there major issues with the Objective-C implementation?
I'd
> be
> > > open
> > > > > to
> > > > > > helping keep it alive. A few things I'd like to see improved:
> > > > > > - Use native number types instead of NSNumber. In 0.9 this
> worked,
> > > but
> > > > > > regressed in later versions.
> > > > > > - Correct nullability usage. Some methods are declared non-null
> but
> > > can
> > > > > > return nil, which prevents proper error handling in Swift and
can
> > > lead to
> > > > > > segfaults
> > > > > > - Improve type safety by replacing some "id" instances with
> > > > > "instancetype"
> > > > > >
> > > > > > Thanks,
> > > > > > Kevin
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Sorry this was sent from mobile. Will do less grammar and spell check
> > > than
> > > > usual.
> > >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message