3

私たちのデバイス(カメラ付き顕微鏡)は、画像と各画像への追加情報を生成します。現在、ミドルウェアサプライは、これらのデバイスをラボ自動化システムに接続したいと考えています。彼らはデータを取得し、私たちがそれを提供しなければなりません。私にとって驚くべきことは、彼らのインターフェースの提案でした-非常に不可解なトークン分離形式(ASTM E1394-97)。残念ながら、彼らはプロトコルに画像を収容することさえできず、ファイルパスを取得することを目指しています。

それは最新のアプローチではないと思いました。代替案を探している間、私はCoachDBを見ました。つまり、私の考えでは、デバイスはCoachDBに画像を含むデータをインポートし、データを取得できるというものでした。口ひげを使用して、必要な形式(ASCIIテキスト)を作成し、パスの代わりに画像参照としてURLを配置できるようです。

私の質問は、誰かがそのようなユースケースにCoachDBをすでに適用したかどうかです。主な目的はデータストレージではなくインターフェイスであるため、CoachDBの少しの誤用のようです。私を悩ませているもう1つのポイントは、CoachDBの発明者が他のプロジェクトCoachbaseに行ったことです。将来的にCoachDBがサポートされなくなるということでしょうか。

洞察や提案をありがとうございました!

4

1 に答える 1

4

これは大丈夫なユースケースであり、実際には、医療検査分析装置とLISの間のミドルウェアをプロキシするなどの方法でCouchDBを使用しています。それらのいくつかは共有フォルダに画像やPDFデータを公開し、それらを添付ファイルとして関連ドキュメントにロードするだけです。

さらに知りたいのは、CouchDBは外部プロセス(別名os_daemons)を提供し、その寿命を管理することです。誰かが終了した場合は再起動し、HTTPインターフェースを介して構成オプションを更新した直後に開始します。このプロトコルは、デバイスと通信して通常のCouchDBクライアントとしてドキュメントを作成するHTTP(CouchDBにネイティブ)とは異なるため、これはASTMクライアントおよびサーバープロセスのセットアップに役立ちます。同様に、特定のファイルの共有フォルダを監視するようにデーモンを設定できます。そして、これはすべて、いくつかの「下限」プラグインを備えたCouchDBです。

于 2013-03-10T10:29:03.393 に答える