thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James E. King III" <jk...@apache.org>
Subject Re: Objective-C support
Date Mon, 22 Apr 2019 12:50:34 GMT
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
View raw message