proposal for new SASL client APIs

[Daiki Ueno]

>>>>> In [emacs-mime-ja : No.00647] 
>>>>>	okada ＠ opaopa.org (岡田 健一 / Kenichi OKADA) wrote:

> > deisui-1_14 枝を flim-1_14 枝に merge しました。
> > より aggressive な開発は、引き続き deisui-1_14 枝でやりましょう。

> まだ SASL APIは変更の可能性はありますか？
> 可能性が低くなったら教えてください．

それは岡田さんの仰る、実地での利用にもとづく評価次第なのですが。^_^;;
ひとまず個人的には FLIM 1.14 に merge した時点で、freeze したつもりです。
;; これにより、現状の SLIM の、肥大化した API は obsolete としたいです。

;; 次期 deisui は、可能な限り luna に癒着したかたちで、完全に OO したも
;; のになると思います。Dia で描いたクラス図(もどき)を以下に置きますので、
;; 興味のある方は御覧下さい。ほとんど elisp ではありませんが。

;; http://www.unixuser.org/~ueno/junk/sasl.eps

;; 当面の目標としては、akr さん御提案の同期型 API を、現状の非同期 API の
;; 上に載せること、sasl-step から data slot を除去すること等が挙げられます。

> 一つ思ったのが、IMAP,POPに固有の問題ですが、
> IMAP にはLOGIN認証(not-sasl)があり、
> POP にはPOP,APOP認証があります．

> わたしの参考コードでは、かなり汚ない方法で対処しています．
> LOGIN認証をSASL-IMAP4-LOGIN認証としてでっちあげて、
> sasl.elの枠組みの中で扱おうとしています．
> SASL以外の認証方式を sasl.el で簡単に扱えたら
> 嬉しいかなと*少し*思いました．
> ;; もちろん、そんなものは SASLじゃないので、
> ;; client側(elmo-imap4.elなど)で対処ればいいと言われれば
> ;; それまでなんですが．

あくまで個人的な予想ですが、これが汚い方法と考えられる理由としては、
そもそも layer が異なる sasl-mechanism への直接の組み込みを前提にして
いるからでしょうか。

簡単に済ませるなら、上記クラス図の sasl-synchronous-client の親クラスに
Adapter を簡単に定義できるような界面を用意しておくとか。

いずれにしても sasl.el に kludge を入れずに済ませるには、裏に更なる抽象
化が必要なので、できれば次期 deisui の実装を待ったほうが良いと思います。
-- 
Daiki Ueno