Wiki RPC Interface への対応†
| バージョン | 1.4以降 |
|---|
| 投稿者 | tset |
|---|
| 状態 | 提案 |
|---|
| 投稿日 | |
|---|
メッセージ†
Wiki RPC Interface は XML-RPC を使った Wiki API の実装で、
Hiki や FSWiki など国内の Wiki も対応しているようです。
参考：XML-RPC とは？，
JSPWiki: Wiki RPC Interface 2
Software Design １２月号の Wiki つまみぐいで特集されていました。
コメント†
- こんにちは。企画ものの話題に興味がおありなら、BugTrackに移して、ページを育てて行くのはどうでしょう。内容についてですが、基本的に「必要な人が創る」のはPukiWikiでも同じです。PHPだと、例のホットなPEARのライブラリがありますね。それと肝心な事だと思うのですが、それでどのような事をしたいのですか？ (実現したいシーンはどのようなものを想定していますか) どこにあるPukiWikiのナニをどこからどうされたいのでしょうか。 -- henoheno
- Wiki RPC が整備されれば、例えば Wiki 専用ブラウザのようなネイティブアプリも汎用的に作れるようになると思います。また、近頃は Web アプリなどで既存の API を活用する機運が高まっていますし、Ajax や Flash などからの Wiki 利用もずっと楽になりそうです。実際問題、本当にインフラが活用されるかどうかは自信が無いところでもあります ＾＾； が、PukiWiki の対応如何は情勢に多分に影響を与えると考えて書き込むに至りました。単なる要望だったのでこちらに書き込んでみましたが、BugTrack、の方が相応しい話題のようであれば移行したいと思います。 -- tset
- こんにちは :) コメントありがとうございます。説明が加わることで、状況や問題がより明確になり、多人数で考える準備が整うと思います。さて、本件は実装よりも前に、運営について明確にしないとまずいと思います。操作を許諾するホスト、許諾するアクションを管理者の任意で制限できないようであれば、Wiki SPAM発信者や、広告営業用ダミーWiki製作者にとって非常に便利な機能を提供することになってしまうと思います。この辺りの話題はすでにどこかで行われているのでしょうか? ないのであれば、キーワードだけ先行している危うい状態だと思いますがいかがでしょうか。 -- henoheno
- 丁寧にありがとうございます。Wiki spam は確かに大きな問題ですね。対策は必要だと思います。henoheno さんが言うような Wiki API の運用的な話は現在十分とは言えませんが、Wiki RPC Interface の仕様は簡素（最低限の操作を XML で代替した程度のもの）なので、対策という面で言えば現状の Wiki 運営とそれほど差は無いのではないか、と私は感じています。Wiki RPC の中で Wiki に変更を加えるメソッドは Wiki RPC Interface 2 から新たに加わった putPage １つで、このメソッドの post 時は通常の書き込みと同レベルのチェックが必要になると思います。PukiWiki の内部構造がまだわかりませんが、匿名扱いの書き込みと同じチェックルートを通れれば良いと思います。設定によって、putPage の利用を制限 （API のバージョンを可変に）できれば安心できるでしょう。ただ、それは spam を修正するような人にとっても不便になるという可能性もありそうですが。ダミー Wiki ですがこれは、API を利用した Wiki のコピーを自動化するツールなどが出てきた場合に悪用される危険があるということでしょうか。これもやはりブラックリストや閲覧頻度など通常のページと同程度の地道なチェックが必要だと思います、が、悪意を持った著作権侵害を公開者側で未然に防ぐことはかなり難しいことのような気もします。 -- tset
![[PukiWiki-official]](image/pukiwiki-official.png "[PukiWiki-official]")
