XMLをアプリケーションレベルのプロトコルとして使用できるかどうかは疑問です。 XMLはTCPプロトコルの一番上に置かれ、2つのアプリケーションはXMLの解析方法を知る必要があります。XMLをアプリケーションレベルのプロトコルとして使用する場合の質問
しかし、問題は、XMLが十分にコンパクトではないということです。 TCPで送信する前にXMLペイロードを圧縮するアルゴリズムを使用する必要がありますか？私がそれを圧縮すれば、圧縮/伸張のコストは両端でかかれます。どのようなジレンマ。良い提案はありますか？あるいは私は間違ったアプローチを取っていますか？
多くのありがとうございます。
は、「十分にコンパクト」の定義しますか？ premature optimisationは避けてください。
は、任意のプロトコルと同様に、様々な方向にトレードオフがあります。 XMLは、すべての種類の構造化データを表現することができる、ほぼあらゆる言語用のライブラリを備えた、よく知られたクロスプラットフォーム形式を購入します。 XMPPはこれを選択し、帯域幅に制約のある設定にオプションの圧縮を使用します。代替表現を使用したXMPPの世界での実験では、その努力にふさわしいことはほとんど証明されていません。
ダウンXMLからのノッチが、それでも利点の多くを提供するには、JSONです。名前空間が存在しないものの、それはかなりシンプルであり、ライブラリはXMLほど一般的です。それでも、JSONはテキストベースであり、状況によっては冗長かもしれません。
最後に賢明な選択肢は、バイナリプロトコルです。これは、アプリケーションに特化してカスタマイズできるという利点があります。欠点は、GoogleのProtocol Buffersプロジェクトなどを自動化するツールがありますが、解析とシリアライゼーションを自分で作成する必要があることです。
は最終的にこれらのすべては、別の場所に適している、と選択肢は、彼らが特定のプロジェクトのために使用すべき1用のアプリケーション開発者に任されています。
私はあなたがあなたのメッセージのためにまっすぐにXMLを使用することができますし、あなたのメッセージがどのように見えるかを指定するための簡単な方法が必要な場合（XMLは正確に驚くほど速くない）圧縮か何かを気にしていないことを言うと思います。より速くコンパクトなものが必要な場合は、Google Protocol Buffersまたはをご覧ください（私は個人的にはプロトコルバッファを好みますが、誰も私のようなものではありません）。例えばXML缶を使用して
はあなたのインターフェイスは、（例えばWebサービスなど）のインスタンスごとに異なる多数のクライアントとの相互運用がしやすいようにするために必要がある場合は良い方法であること。一方、常にコミュニケーションの両端を担当している場合は、いつでもすぐに何かをやって行くことができ、後で最適化することができます。あなたはそれがあなたのアプリケーションのために遅すぎることが測定されている