software

web service

newsclip

次世代NewsClipのアイディア。

チャンネル

  • チャンネルデータはCVSサーバーで集中管理する。これぐらいのトラフィックであれば弱小サーバーでも大丈夫
  • 処理キューはこのサーバーが管理する。巡回サーバーは処理キューを見て、巡回すべきチャンネルを知る。
  • 各チャンネル、各巡回ごとに別の暗号鍵を付与する。巡回サーバーはその鍵をつかって記事を暗号化する。UIサーバーもその鍵をもらって展開する。
  • つまり、個人情報のサーバーとチャンネルサーバーは一体化していたほうがよい。

巡回

  • この処理がいちばんネットワーク/サーバー負荷が大きいので分散化させたい。
  • 巡回サーバーは分散配置する。分散したサーバー間で協調動作するのに共有ネットワークを利用するが、記事の再送信とならないよう、暗号化する。
  • 巡回サーバーは、定時にチャンネルを入手し、それに従い巡回して結果のディレクトリツリーをアーカイブし、暗号化して共有ネットワークに放流する。
  • rebuildサーバーはアーカイブをつりあげては、それのplucker/iSilo/textバージョンを再生成してそれも暗号化して放流する。
  • 巡回サーバーは個人情報にはアクセスできない。
  • 巡回サーバーは、チャンネル情報を受けとり、巡回し、.torrentファイルを返す。
  • rebuildサーバーは.torrentを受けとり、ファイルを取得し、変換を行い、.torrentファイルを返す。
    • .torrentは動的に生成されなければならないので、中央サーバーに集約できないかもしれない。しかし一方で、巡回サーバーは常にaliveとは限らない。最初の巡回だけ巡回サーバーで行い、あとは中央サーバーに任せる、といった形態は可能か?

ユーザー情報の管理

  • ユーザー情報も一箇所で集中管理してよいだろう。
  • ユーザー認証が成功したら、記事を展開するための鍵束をクライアントに渡す。

UI

  1. ユーザー情報サーバーの情報に従い、共有ネットワークから必要なファイルをつりあげ、パックし、提供する。(従来のNewsClipサーバーとの互換性を保つ)
  2. ユーザー情報サーバーで認証して各記事の鍵をもらい、クライアントが共有ネットワークから直接必要なファイルをつりあげ展開する。
    • 誰が古いチャンネルを消すか、どうやったら共有ネットワークから消えるか。
    • 共有ネットワークは十分信頼性があるか。
    • apt-getのような既存の仕組みを流用できないか。
    • BitTorrentだと、放流源が固定されている(?)ので、分散巡回したあとのファイルを中央に戻す必要があるかもしれない。–>.torrentファイルだけを中央に戻せばよさそうだ。
    • チャンネルの編集は誰がどこでどうやって行う?仕様書を公開して、誰でも作れるようなスクリプトのような形にするか? - matto
    • これらを実現したとして、現在のNewsClipと同じものはできる。その先、何が必要か。 - matto
    • チャンネル一覧、チャンネル選択はどうする? - matto
    • 巡回サーバーは、例えばdebianのパッケージをひとつインストールすれば自動的に巡回がはじまる、ぐらいシンプルにする必要がある。巡回サーバーの所有者にメリットがあるような仕組みが欲しい。 - matto
    • 人と人をつなげる機能をもっと充実させたい。NC-Fan2は本来NewsClip UIの中にあるべき。 - matto
    • 世界時間、多言語対応。 - matto
    • RetrievRのように、On-demandだが非同期で巡回するというやりかたもある。 - matto
    • https://sourceforge.jp/projects/newsclip/ で開発する。 - matto

Linked from

Edit