mikutter

先日Twitterで言っていた件ですね。私も基本的には反対もしませんし、新しい名前に変更するなら従来のspecという名前はduplicatedにして新しいものに統一することには賛成です。

• メタファイルの名前ですが、.mikutter_pluginでは、このファイル自体の役割の説明としては適切ではないと考えます（これ自体がプラグインというわけではなく、単なるメタファイル、定義ファイルです）。
• アクティビティに「warining」ロールを追加するのは、あまり細かく共通のロールを作りすぎると、それらの役目を明確に定義しないとデベロッパが正しい分類を出来ず、結果としてユーザにとってこの分類が無意味になるだろうと考えているため、単純にこれ以上追加することには懐疑的です。現在明確な定義が無いため、以下の様な対策をとる必要があると考えます。
  • systemロールのメッセージにする(Miquireモジュールもプラグインロード時にバージョン不整合を検出するとこれを使います)。
  • warningを新設し、分類規約の必要性を検証し、必要に応じて定義する。他の標準プラグインの通知のロールを新しい規約に照らしあわせて修正する。

どちらも、私自身特に考えがまとまっていない状態です。取り急ぎ考えていることを書いたまでです。何か意見があればお願いします。二点目に関してはこのチケットから逸脱していますが、話が大きくならない限りこのチケットで済ましてしまいましょう。

まず、メタファイルの名前のほうですが、これはちょっと悩んだ結果でもあります。
このファイル自体がプラグインでないというのはその通りなのですが、ファイル名に入れたい情報としては

• mikutter関連のファイルであること
• プラグインに関わるファイルであること

• .mikutterrc
• .mikutterpluginrc
• .mikutter_plugin_spec
• .mikutter_plugin

などを候補として考えました。
このうち.mikutterrcはプラグインという情報が入っていないので今ひとつかなと思い、2つ目と3つ目はファイル名が長すぎて美しくない気がして、結局4番目にしてみたという経緯があります。
ただ、現状mikutterに関連するファイルでmikutter本体でないものはプラグイン以外あり得ないので、プラグインという情報は削って.mikutter.ymlみたいな感じでもいいのかな、という気もしています(.travis.ymlみたいなノリで)。
そんな訳で、個人的には.mikutter_pluginか.mikutter.ymlを推しますが、最終的な決定はおまかせします。

warningロールについては、systemロールでdeprecatedを報告すると、正常動作はしているのに警告が流れてくる、しかしユーザーにはどうしようもない、という状況が発生してしまって、それはどうなのかなぁと思ったので別に作った感じです。
まあ、仕様変更に気づかれない方が危ないというのも確かなので、mikutter本体レベルであえてロールを増やすほどの必要はなかったかもしれません。

名前に関して、確かに、1でも書いたとおり、これといった代案はありませんでしたが、 .mikutter だけだと情報が少なすぎる気がしますね。プラグインであることもわかっているので、個人的には .mikutter.yml が気に入りました。

ロールに関しては、よく考えたら現状 spec がないプラグインに関してメッセージを出さないのに、systemロールで通知するのは不自然ですね。
もっとも、定義ファイルが一切ないプラグインは書き捨てなのでそういう警告自体ナンセンスだという考え方もあると思います。その場合は、プラグインユーザ全員に警告が出ることで、ユーザには早くアップデートしようと思うこと、開発者は早くアップデートをすることをそれぞれ期待していました。
思いつきですが開発者のSNが定義ファイルには書いてあるので、自分で作ったものはsystemで報告して、ユーザにはwarningで報告するといった仕掛けも楽しそうですね。consoleプラグインなどがそうですが、mikutterにはmikutterプラグイン開発の補助ツールとしての側面もあると考えているので。
なんだかまとまらないので、「アクティビティのロールを考えなおす」というテーマで別チケットにしてしまったほうが良いように思いますがどうでしょう。