プロトタイプの仕様議論

[ksato9700]

3 とも関連しますが、aozora.jsonやhinagataの仕様を煮詰めたり、kosakuinのあるべき姿を模索するためにプロトタイプづくりを進めたいと考えています。具体的には

• パッケージ受け付け、配布サーバ
• パッケージ投入スクリプト

をまずは考えています。仮に前者を pubserver (publishing server)、後者を aopm (AOzora package manager)と呼びます。これらのツールが満たすべき要件とそれを実現するための仕様をここで議論し、プロトタイプに実装していきたいと思います。

[ksato9700]

なお、pubserver に関しては ksato9700/pubserver で少し作り始めています。

[ksato9700]

pubserverをファイルアップロード対応してみました。

簡単な説明を READMEに書きましたが、zipファイルで包んだテキストとaozora.jsonを送るだけです。アップロードしたメタデータとファイルは/books API経由で見られます。サンプルの仮パッケージはコチラ。

もちろんaozora.jsonのフォーマットも仮ですし、テキストもaozora.txtという名前決め打ちですが、ファイルアップの仕組みの確認のために取り敢えずそれで実装してあります。実際にはテキストファイルの名前は任意で複数ファイル可、それをaozora.jsonで指定するのかなと思います。詳細はaozora.jsonで議論させてください。

それで、このpubserverのソースをkosakuin配下に持ってきたいのですが、簡単なプルリクエストではうまくいかない気がします。どうしたら良いでしょうかね。 @takahashim さんあたりの知恵を拝借したいところですが...

[takahashim]

@ksato9700 issueやpull request、Wikiなどを引き継がないのであればforkしてaozorahack下に持ってくるのが簡単なんですが、それでも構いませんか？

[ksato9700]

なるほど。いや、それでも良いかなと思ったのですが、またリポジトリが増えてしまうかなと。ま、説明書きをちゃんとすれば大丈夫ですかね。。。issues, PR, Wikiなどは使っていないので大丈夫です。

[cognitom]

思ったよりもリポジトリの移管が大変なので、乱立を気にせず、ポコポコ立てちゃうのも手かもしれませんね。

APIサーバと、公開サーバは別という想定でも良いように思いました。例えばですが...

• 公開サイト: kosakuin
• APIサーバ: kosakuin-api
• パッケージ投入スクリプト: kosakuin-cli (あるいは aopm)

みたいなリポジトリ構成はわかりやすいかも?

[ksato9700]

でも、きっとAPIサーバと公開サーバは一緒になるんじゃないかと思います。実際、pubserverでそういう実装になっちゃってます。aopmは分けれるかもですね。それをkosakuinの下で始めても良いのですが。

[cognitom]

ですね。なんとなく、公開サイトとAPIを違う言語で書く余地を残したいような...? SPAっぽくするなら、フロントとAPIという構成もアリ。 ま、ひとまず、kosakuinの中に入れておいてあとで分けるのでも、構わない気もしてきました。

[ksato9700]

サクッとkosakuinの下に入れられればそれでも良かったのですが、自分でリポジトリ立てて始めてしまったので、aozorahackに持って来るにはそれをそのままforkするのが一番ラクみたいなんですよね。

まずはそうして、取り敢えず全部入りのごちゃ混ぜでプロトタイプするというのでいかがでしょうか？

ある程度まで行くとどうせ作り直したくなるので、その際に機能分割した形で本番実装の為のリポジトリを立てるということで。

[takahashim]

ここでいう「公開サイト」が何を意味しているのかわかりかねますが(https://github.com/aozorahack/kosakuin/issues/1#issuecomment-109519514 で言うと「青空文庫サイト」になりそうだけど、APIがあるのもここだけなのでちょっとよく分からない)、青空文庫のwebサイトや、それに準じるサイト（β版的なものや私家版的なものを集めたサイトとか）については、完全に静的な構造にしておきたいという要望は少なからずあるかと思います。が、そこでも動的な機能が欲しいという意見も確実にありそうで、これは決着がつかないかと。

APIサーバにしても、Goでやりたい人とJSでやりたい人とJavaでやりたい人とかが出てくると合意がとれる気が全くしない（それぞれ一長一短ある）ので、とりあえず個別の方針はレポジトリ毎に作って、必要な機能は複数のレポジトリにまたがって連携させるような形になるかなあ、と思っています。

[takahashim]

というわけで、pubserverはpubserverで取り込んでおきますね

[cognitom]

先日、 @ksato9700 さん @key-amb さんとで話していた時は、ひとまず裏青空文庫的な勝手サイトを目指して、揉んでみようという話になっていました。「夜空文庫」という名称案も。

完全に静的な構造

は確かに。その場合、

• API
• 静的サイトジェネレータ
• 出力データ置き場 (gh-pages)

みたいな構成になるでしょうか。静的サイトジェネレータは、ツールさえ整ってくればmakeかgulpでも構わないかも。

[ksato9700]

@takahashim さん pubserverのforkありがとうございます。今後はこちらを本拠地とします。

そして、仰るように各種言語でやりたい人が出てくるのかなと思います。そういう方々にも興味を持ってもらう意味でも、オープンな仕様をプロトタイプを通じて固めて行ければなと思っています。