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 Wed, 01 May 2019 01:48:47 GMT
Bringing back ObjC would be great. We could generate several bug fixes to
keep it going a few more years. Is there more documentation about the test
infrastructure? I didn't see much more than the read me, but I could dig
into it more.

Kevin


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

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message