Restcomm アプリで RVD を使用して基本データまたは基本ロジック ツリーを作成する方法がわかりません。次のコンポーネントを作成する方法はありますか?
このようなコンポーネントを使用すると、アプリ開発者は、すべてのアプリ ロジックを管理するためにインフラストラクチャを立ち上げる必要がなくなり、より多くの自己完結型アプリを作成できるようになります。
現在のコンポーネント API は新しいコンポーネントの開発をサポートしていますか?
RVD は、ユーザーに最大限の柔軟性を提供することと、反復的なアプローチに従いながら開発労力をできるだけ少なくすることとの間の闘争の結果として生まれました。常に機能的な進歩したアプリケーションを持つために、小さなステップで進化しました。これらの要件を満たすために、非常に重要な設計上の決定が下されました。つまり、コア部分 (コントローラー) を単純に RCML を生成するダミー エンジンのままにし、すべてのロジックを別の場所に委譲し、HTTP 経由で簡単にアクセスできるようにすることです。
そうは言っても、@ scottbarstow、コメントを歓迎します。自己完結型のアプリを使用すると、アプリケーションのセットアップとメンテナンスが大幅に簡素化されます。特に RAS が登場した現在ではなおさらです。ES は、あらゆる種類の複雑な操作を RVD の外部に委任する方法ではなく、実際に外部のターゲットと対話するためのツールであるべきです。
ただし、「ロジック」にはコストがかかります。分岐、比較、文字列操作などのためのいくつかの要素を導入するには、多くのことを考えて設計し、実装するのに何時間もかかり、デバッグするのに頭を悩ませる必要があります。
私が提案する代替アプローチは次のとおりです。
ES が外部エンドポイントと通信する方法を改善します。POST/JSON ペイロードを送信するための完全なサポートを追加します。application/json と URL エンコードされたフォームのコンテンツ タイプのいずれかを選択できます。Slack などの一般的なサービス プロバイダーが通常必要とするその他すべてを処理します。すべての処理は ES で行われます。ここでさらにフィードバックをいただければ幸いです。
すべてのロジックを複数の新しい要素に分散させるのではなく、1 か所にまとめます。ある種のスクリプト エンジンを使用して、必要なすべてのロジックを実装するコード ブロックを実行する "Script" 要素を導入します。この要素は、"IN" と "OUT" を使用した単純な文字列ベースのコントラクトを通じて外部と通信します。Groovyを使用した実験的な実装が既にあり、サーバー側のJavascript でも同じことができます。
でも、ちょっと待って。RVD は、開発者向けではなく、一般ユーザー向けのシンプルなツールです。 そうですね。しかし、代替案を検討してください。多くの新しいスマートな要素と、それに伴うすべての追加された構文の意味を理解して使用するのは簡単ですか? 非常に基本的なものでない限り、そうではないと思います。デバッグとサポートは言うまでもありません。
Javascript の構文はよく知られており、デバッグがはるかに簡単です。クライアント側のテスト用のウィンドウを開くブラウザー内でも実行されます。
- 非常に基本的な分岐/GOTO 要素を導入します。モジュールの実行を中断し、別のモジュールにリダイレクトできます。ただし、分岐のロジックは前の Script 要素で実装されます。
技術的な欠点と「なぜロジックを 1 つのブラック ボックスの場所に保持する必要があるのか」
RVD には状態があります。保存する必要があるRestcommによって供給される変数に加えて、それが作成する変数があります（Collect、ES要素はそのようなものを作成します）。アプリケーション フローは、本質的にステートレスな一連の restcomm 発信アクション リクエストとして進行するため、2 つのオプションがあります。
(a) アクション URL でこれらの変数をリサイクルするか、
(b) それらを RVD のセッションのような構造に格納し、代わりに転送されるセッション ID を保持します。
RVD は (a) を使用します。
つまり、制御が restcomm に戻されるたびに (Gather/Collect 要素が実行される場合など)、この状態はすべて、応答に含まれるアクション URL にエンコードされる必要があります。そうすれば、restcomm が次のリクエストを行うと、RVD は状態になります。HTTP セッションのない古い学校の Web 開発者と多かれ少なかれ同じパターンです。
RVD と Restcomm の間で大量のデータがやり取りされないように、この状態は小さくする必要があります。
RVD アプリケーションは、順次処理される要素を含むモジュールで構成されており、いずれの要素も RVD でアプリの実行を中断し、コントロールを restcomm に戻す可能性があります。アプリケーションの実行を中断し、Restcomm に制御を戻すオプションがあるように、要素を独立させることは理にかなっています。
要点は、要素を独立した状態に保ち、要素と RVD 実行コンテキストの間のインターフェイスをシンプルにし、状態を簡単にシリアライズできるようにする必要があるということです。そして、Script 要素のようなブロック ボックスは、この目標に適合するようです。
RVD でスクリプトを有効にするのは比較的簡単です。ただし、アプリケーション コードのバグに対処するための適切な方法は明らかではありません。経験の浅い開発者は、動的で緩く型付けされたスクリプト言語を使用すると、すぐに失敗する可能性があります。
RVD の当初の目的は、シンプルなリアルタイム通信アプリを本当に簡単に作成できるようにすることでした。より複雑なことを可能にするために RVD の範囲を拡大すべきか、それとも外部サービスに委ねるべきかは、まだ未解決の問題です。
実装しようとしているアプリを詳しく調べてもらえますか? SMS や音声通話の録音を取り、Slack などのサード パーティ サービスに送信する場合は、Zapier などのサービスを通じて実現できます。WordPress プラグイン (Gravity Forms) から Slack への接続を示す添付のスクリーンショットを参照してください。
Restcomm の同様の Zapier モジュール (Gravity Forms の代わり) は役に立ちますか?
