[Date Prev][Date Next][Thread Prev][][Date Index][Thread Index]

Re: Shimbun backends based on RSS 

>> On Sun, 22 Jun 2003 09:06:34 +0900
>> minakaji@namazu.org (NAKAJIMA Mikio) said as follows:

>> (1) RSS に基づく backend か否かは，開発者の視点からは意味のある情報で
>>     すが，ユーザーの視点からは冗長な情報だと思います．つまり，*-rss.el 
>>     というファイル名は，冗長なファイル名と考えられますから，ファイル名
>>     の重複を避けるなどの，やむを得ない場合を除き使わないことにしません
>>     か．
>> 
>> (2) 同じサーバーに対して，複数の実装が存在する状況はあまり好ましくない
>>     と思います．将来のサイト改変などに対応する労力が，二重になってしま
>>     いますから．ですから，両方の実装を比較して，優れている方を残すよう
>>     に整理するべきではないでしょうか．
>> (snip)
>> (4) RSS に基づく backend についても，対応しているサーバーとグループに
>>     ついての情報を，きちんと Info に追加するようにしましょう．

>ご提案の趣旨了解しました。(1), (3), については賛成なんですが、(2) に
>ついてはいずれが優れているのかもう少しゆっくり検証してからいずれかに
>絞り込むようにしませんか。

そうですね，おっしゃる通りだと思います．

(2')同じサーバーに対して，複数の実装が存在する状況はあまり好ましくない．
    この状況は，過渡的なものであると認識して，整理する方向で努力しよう．

と訂正します．

>ファイルを消すのは簡単ですが、消した後にやっぱり RSS の方が...(あるい
>はその逆)ということになり、消したファイルをまた復活させてそれを修正し
>て...という起り得る手順を想像すると非常に手間です。

消すというより統合ですから，cvs で元の版に戻すこと自体はとても簡単だと
思うのですけど．

>それに既存の backend についても、RSS が提供されている場合、rss 版を別
>途作成してみる (そしていずれが優れているかを検討する)、ということもあ
>り得ると思うのですが、この場合もやはり併存させてしばらく様子を見ると
>いう方が良いと思います。

>そして開発者がいずれかに統合したいと考えた際、統合提案のアナウンスをし
>て、cvs 版ユーザの意見を吸い上げる期間を設けた方が、統合後にユーザから
>問題提起される可能性を減らすことができ、より安全でしょう。

それは，各 committer の意向次第だと思っています．中島さんのように慎重
に移行されるのも良し，いきなり移行されるのも良し．ユーザーからのバグ報
告などに対して適切に対処されている限り，移行手順についてあまりとやかく
問うことは必要ないと思います．

>基本的には web design の将来の変更の可能性を考えると、RSS が提供されて
>いる場合は可能な限り rss 版を使用した方が堅牢性が増すと考えます。

それは同感です．現時点で言えば，CNet は RSS 版の方が優れているのでは，
と思っています．Slashdot-JP についてはちょっとややこしくて，RSS では最
近の記事しか読めませんが，現行版では古い記事も探して読むことができるの
で，どちらが良いかちょっと悩んでしまいます．

>(4) についても勿論賛成は賛成なんですが、リリースの準備段階とか、その
>ませんか。色々仕事が増えて負担が増える一方で、リリース直前に、この
>backend 要らない、この backend はバグがあるのでリリースから外すという
>ことになれば、時間を費やしてやった仕事が無駄になる (あるいは更に info 
>から削除するという余計な手間が増える) ことになるからです。

あの，以前から README.shimbun.ja に記述を追加するという約束はあったは
ずで，それが Info に変わっただけのはずなので，余分な仕事を増やすという
提案ではないのですけれど．

おっしゃる通り，リリース直前にまとめて対処するのも一つのやり方ですが，
個々のバックエンドを変更したり，新規作成したりした時点で逐次的に文書を
変更していく方が，

(1) 作業内容の記憶が風化する前に作業した方が，見落としが少ないことが期
    待できる．
(2) リリース時に，全ての committer に余力がある(= 文書の見直し作業をお
    願いできる)ことは期待できない．
(3) 内容を追加する方は実際の作業者でないとできないことが多いが，削除す
    る方は簡単．

という理由から良いのではないかと考えています．

-- 
土屋 雅稔 ( TSUCHIYA Masatoshi )