誰もiPhoneアプリでApache Thriftのデプロイメントを行ったり、見たことがありますか？iPhoneでApache Thriftを使用して成功しましたか？
私は、HTTPと比較して、iPhone用の大量で低容量のネットワークサービスの合理的な解決方法があるのだろうかと思います。
私が見つけた注目すべき1つは、iPhone上で実行されているThriftについてのbug reportです。これは修正されているようです。しかし、必ずしもそれが完了した取引であるとは限りません。
私は、サーバーコードとクライアントコードの両方を構築する共通のインターフェイス定義を使用するフレームワークを常に嫌ってきました。現実にはサーバーAPIの変更は、通信しているクライアントのバージョンに非常に柔軟性がなければなりません。
HTTP経由でのJSONまたはPLIST通信を非常に簡単にし、HTTPプロトコルのデバッグと理解とそれをうまく使用するための有用なライブラリがあります。私はあなたの危険にそれを無視します。
外部APIとしての倹約は意味をなさない。内部でロックンロールします。
倹約とHTTPは互いに排他的ではありません。現実には、使用するためのHTTPトランスポート実装が付属しています。それは、サーバー/クライアントコードを自動生成する本当に良い方法でもありますが、まだまだ速いうちに定型化を整理/整列解除する必要はありません。その内部表現は基本的にバイナリJSONなので、RESTful Webサービスと非常によく似ています（コード作成が簡単で、はるかに高速です）。
だから誰も元の質問に答えることができますか？もしそうでなければ、私は倹約の含まれているココアのサポートと自分自身でダイビングし、それがiPhoneで動作する方法を参照してください。
更新していただきありがとうございます！ – JasonSmith
私は、数百万人のユーザーを抱える大規模なiPhoneアプリに対して、thriftの目的のCバインディングを使用しました。言及されたポスターの1つとして、我々は両方の世界の最高を得るHttpを使うことができます。しかし、倹約のための非同期HTTPクライアントはありません。ノンブロッキングI/O呼び出しを可能にするイベントベースのラッパーを構築しなければなりませんでした。 1つのサーバー呼び出しで時間がかかるが、UIフローをブロックしたり、UIフローをブロックする非常に速い呼び出しをブロックしたりすることはないので、一度に1つの呼び出しが同時に発生します。基本レイヤーが低速コマンドでビジー状態の場合、高速コマンドは待機するだけです。私はC + +のasyc httpのを構築しようとしているが、それはiPhone上で使用することができますが、それは多分準備からオフです。ちょうど私の2セント
..
この質問への受け入れ答えは、技術ではなく、それが可能かどうかの答えを使用しないように意見です。
Thriftは、ProtobufやCapt'n'Protoのようなインタフェース定義言語のIDLです。これらは、プラットフォームに依存しないクライアント/サーバ/サーバプロトコルの定義を可能にする。 JSONとPlistは、同じレベルの型の適合性を提供しません。
iOS、Android、Windows、およびサーバーチームでGoogle Protobuf v2.5を使用して、以前は10Ms MAUでiOSチームを率いていたので、IDLはモバイルで優れていることを証明できます。 AppleはiWorkコンテンツの同期にこれらを使用します。
私の現在のチームでは、iOSとAndroidクライアントではScriftバックエンドが主に使用されています。私はProtobufにそれを好む。
私たちは、HTTPSとWebSocketを介してThriftペイロードを送信します。ワイヤ通信プロトコル（フレーム構造）を（倹約して）定義したら、APIを進化させるのは非常に簡単です。
しかし、特にiOSでは実装上の問題があります。現在のバージョンのライブラリはパッケージ化されていないため、Objective-Cフレームワーク（iOS 8+など）を作成したい場合は、v0.9.2ですぐに使用することができません。これは、ライブラリヘッダーには、傘のヘッダーを持たないローカルインポート（#import <Thrift/TProtocol.h>の代わりに#import "TProtocol.h"）が含まれているためです。最悪の場合、Objective-Cコンパイラは、Thriftライブラリからのローカルインポートを含む非常に面倒なObjective-Cクラスを生成します。
これらの問題のいくつかはかなり害です。 IDLの使用は非常に優れた設計上の決定ですが、多くのiOSチームが自分のライブラリを作成するリソースが膨大でない限り、Thriftを使用していないことを私に示しています。
受け入れられた回答についてのあなたのポイントは有効です。 （それ自体はメタ・ディスカッションではありますが、スリフト自身についての答えではありません）。答えについてのスタック・オーバーフローのポリシー/ガイドラインが明確でよく知られていないうちに、私は5年以上前の答えを受け入れました。 – JasonSmith
@JasonSmithはそれが受け入れられた答えであることに問題はありませんでした。その質問はかなり古いことに気づいた。しかし、SOはそれを最新の状態に保つようにしなければならないので、私は自分の2セントを追加しました:) –
ありがとう、ケンドール。私はリスクについてあなたに同意します！私は新しい質問をすることを検討しています：いつ、そしていつ、なぜ、HTTPから離れるのでしょうか？私にはそれは支払う急な価格です。 まだ100万人のユーザーに近づいているiPhoneアプリが成功するには、スピードを落として待ち時間を短縮するために、逆方向に曲げる価値があるかもしれません。 （私は懐疑的です。ほとんどのiPhoneアプリはデータ駆動型であり、シリアライゼーションは問題ではなく、待ち時間は助けられません）。私は広範なコミュニティからの感触を知りたいと思います。 – JasonSmith
具体的には、ロケーション情報などのハンドセットからの重要ではないアップデートに対して、UDP経由でバイナリシリアル化を使用することを検討しています。私はまだ説得されていないが、私はそれに開いている。 – JasonSmith
実際には、それほど簡単ではない可能性があります。私は訂正した。 –