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 17:00:59 GMT
Releases for this project are very expensive.  We have about 28
languages to support.  It would make more sense to reinstate the objc
code for the next major release if people are still using it and the
premise that everybody is moving to Swift was in fact unfounded.  In a
project this complex, removing unused languages is one way to reduce
the maintenance burden, which is why it was removed.  With more active
participants, that is less necessary.  It would also be helpful if we
had people actively maintaining it, and if we had cross language test
support to make sure it was actually working.

- Jim

On Mon, Apr 22, 2019 at 10:42 AM Kevin Wojniak <kwojniak@box.com.invalid> wrote:
>
> 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
View raw message