Service Bus Track2で実行する必要のある作業を分析する必要があります。Track1はすでにリリースされています。
仮定:
聞く:
azure-core-amqp
に移動する必要がある一般的なコードの問題を作成します。必要な説明:
完全に書き直す理由は何ですか? 顧客が図書館の方向性とその理由を理解できるように、方向性や高レベルの設計ドキュメントを共有できますか?
ストレージライブラリのリライトに起こったのと同じような望ましくないリライト状況が発生するのではないかと心配しています。 問題の率直な議論については、 https://github.com/Azure/azure-storage-java/issues/432を参照してください。 すべてのフィードバックを聞いた後、そのライブラリに取り組んでいるチームは、優れた方向性ドキュメントを共有しました: https ://github.com/Azure/azure-storage-java/blob/master/V12%20Upgrade%20Story.md
ここで透明性のために提供されたそれらの線に沿って何かを見るのは素晴らしいことです。
こんにちは@jordanjennings 、この質問をしてくれてありがとう。 明確にするために、Microsoft内では、多くの最上位プログラミング言語向けに、Azure用の新世代のクライアントライブラリを提供するための取り組みが進行中です。 Storageからリンクした説明は、ここに関連しています。V12は、Storageに対して行った「書き換え」であり、ServiceBusについても同様です。 詳細については、最初のプレビューリリースの発表をご覧ください。
@hemanttanwarがここで言っていることは、過去数か月間行ってきたように、Service Busの一貫した、慣用的で生産的な開発者エクスペリエンスを保証するために、レビュー、設計、および実装の同等のプロセスを開始しようとしているということです。 興味深いと思われる高レベルの設計ドキュメントは、私が作成したJavaAPI設計ガイドラインドキュメントです。 このドキュメントは、V12 Storage API、および将来のすべてのJavaクライアントライブラリ(その多くは現在開発中および/またはプレビューリリース状態にあります)をガイドしたものです。 ご質問やご不明な点がございましたら、お気軽に直接メールでお問い合わせください。
#4506で修正
最も参考になるコメント
こんにちは@jordanjennings 、この質問をしてくれてありがとう。 明確にするために、Microsoft内では、多くの最上位プログラミング言語向けに、Azure用の新世代のクライアントライブラリを提供するための取り組みが進行中です。 Storageからリンクした説明は、ここに関連しています。V12は、Storageに対して行った「書き換え」であり、ServiceBusについても同様です。 詳細については、最初のプレビューリリースの発表をご覧ください。
@hemanttanwarがここで言っていることは、過去数か月間行ってきたように、Service Busの一貫した、慣用的で生産的な開発者エクスペリエンスを保証するために、レビュー、設計、および実装の同等のプロセスを開始しようとしているということです。 興味深いと思われる高レベルの設計ドキュメントは、私が作成したJavaAPI設計ガイドラインドキュメントです。 このドキュメントは、V12 Storage API、および将来のすべてのJavaクライアントライブラリ(その多くは現在開発中および/またはプレビューリリース状態にあります)をガイドしたものです。 ご質問やご不明な点がございましたら、お気軽に直接メールでお問い合わせください。