0

通常は正常に動作する自作の CalDAV 実装がありますが、問題が 1 つあります。モバイル ネットワークを介して同期される何百ものカレンダーを持つクライアントがあります。iCalendar が深さ = 1 で PROPFIND を要求するたびに、サーバーはカレンダーの完全なリストで応答する必要があり、モバイル ネットワークが不安定なために時々失敗する巨大な応答を返します。

応答を小さなチャンク (応答ごとに 30 など) に分割すると役立つと思いますが、それが本当に可能かどうかはわかりません。

質問は - N カレンダーのチャンクによる連続したリクエストで、クライアントに PROPFIND カレンダーを強制することはできますか?

4

3 に答える 3

1

いいえ、これについて合意された基準はありません。

そうは言っても：（1）応答を圧縮していますか？(2) https://datatracker.ietf.org/doc/html/draft-murchison-webdav-prefer-05を見ましたか?

于 2013-11-25T10:12:02.260 に答える
0

ブラッドが述べたように、カレンダーの数とカレンダー内のイベントの数を区別する必要があります。

何百ものカレンダーを持つことは非常に珍しいことですが、それでいいのです。100 件の結果を含む PROPFIND は、それほど大きくありません。また、CTag にも注意してください。それが利用可能な場合は、最初にカレンダーの内容を同期する必要があるかどうかがわかります。

ほとんどの場合、多くのイベントを含むいくつかのカレンダーについて質問している可能性が高く、数千になる可能性があります。このような場合、ETag を取得して変更を確認するためのカレンダーの PROPFIND:1 は、大きくなり遅くなる可能性があります。(いずれにせよ、Accept-Encoding: gzip および Brief:T をサポートしていることを確認してください)。

この場合、RFC による解決策があります: RFC 6578 です。同期レポートを使用すると、最後の同期以降に変更されたレコードを返すだけで済みます。iOS と iCal でサポートされています。この仕様はバッチ処理 (RFC では切り捨てと呼ばれます) もサポートしていますが、これはすべてのクライアントに実装されているわけではありません。

于 2014-02-27T00:44:42.420 に答える
0

「100 のカレンダー」とは、「100 のイベント」のことですか? 数百の項目を含む PROPFIND 応答は実際には大きくないため、これは完全に正常です。しかし、多くの場合、カレンダー内のイベントのリストは大きくなる可能性があります。しかし、Apple は通常、非常に優れた caldav クライアントを使用しており、適切な日付範囲で REPORT リクエストを実行して、イベントが多すぎないようにする必要があります。

Caldav サーバーがすべてのレポートを実装していない可能性があるため、クライアントはより単純なアプローチにフォールバックしています。

于 2013-11-25T23:48:38.937 に答える