FLIM 1.14 API (Re: flim-1_13-rfc2231 vs flim-1_14-rfc2231)

[Shuhei KOBAYASHI]

>>>>> In <861yqc9ue3.fsf ＠ aqua.ocn.ne.jp>,
>>>>> Shuhei KOBAYASHI <shuhei ＠ aqua.ocn.ne.jp> wrote:
> FLIM の RFC 2231 対応の main trunk への merge を検討しているのですが...

これに関連するのですが, FLIM-API.en に関していくつか質問があります.

`mime-parse-Content-Type' に関する記述が 2 か所に出てきますが,

| * MIME content information
| 
| ** How to use
| 
| (require 'mime)
| 
| 
| ** Content-Type
| 
| [Function] mime-parse-Content-Type (string)
|   Parse STRING as field-body of Content-Type field, and
|   return the result as `mime-content-type' structure.

[...]

| * MIME Field parsing
| 
| ** How to use
| 
| (require 'mime)
| 
| 
| ** Level 2 features
[...]
| [Function] mime-parse-Content-Type (string)
|   Parse STRING as field-body of Content-Type field.
| 
| Return value is
|     (PRIMARY-TYPE SUBTYPE (NAME1 . VALUE1)(NAME2 . VALUE2) ...)
| or nil.  PRIMARY-TYPE and SUBTYPE are symbol and NAME_n and VALUE_n
| are string.

Q1. "Level 2 features" って何ですか?

std11 の方には "Level 1 features" という記述もあるみたいですね.


Q2. ("Level 2 features" では?) `mime-content-type' 型の構造まで定めて
    しまうのですか?

Q2-1. 現在の FLIM 1.14 実装とは `mime-content-type' の構造が異なって
      いますが, これは FLIM 1.14 実装の bug なのでしょうか?

Q2-2. IMAP4 では parameter list を alist ではなく plist で表現してい
      ますが, FLIM の特定の実装でも同様に plist を採用するというのは
      許容されないのでしょうか?

Q2-3. `mime-content-type-parameters' の返り値の型は?

| [Inline function] mime-content-type-parameters (content-type)
|   Return parameters of CONTENT-TYPE.

`mime-content-type' 型の構造が API に含まれないとなれば, この関数の返り
値の型は実装依存になりますね. そもそも, `mime-content-type-parameter' と
`mime-content-type-parameters' の両方があるのは冗長ではないですか?

>>>>> In <861yqc9ue3.fsf ＠ aqua.ocn.ne.jp>,
>>>>> Shuhei KOBAYASHI <shuhei ＠ aqua.ocn.ne.jp> wrote:
> このため flim-1_13-rfc2231 とは異なり, API の拡張[*]は不要になっています.

flim-1_13-rfc2231 が「API の拡張」と呼ぶところの変更は `parameters' を
外に見せているために必要となったもので, `mime-content-type-parameter'
だけを使用していれば API の変更は不要ではないでしょうか?
;; language info 関連を除く.

あ, "[Inline function]" と規定しているのも問題ですね.
`mime-content-type' 型の詳細を隠蔽できなくなってしまいます.
守岡さんは(or FLIM API では) *.elc の互換性は気にしないのでしたっけ?


Q3. `make-mime-content-type' は API に含まれないのですか?
    `make-mime-content-disposition' は? (現在の FLIM 1.14 実装では未定義)


RFC 2231 からは離れますが,

| [Function] mime-entity-encoding (entity &optional default-encoding)

| [Function] mime-read-Content-Transfer-Encoding (&optional default-encoding)

Q4. `default-encoding' は不要ではないでしょうか?
    実際, FLIM 1.14 でも `(or (mime-entity-encoding entity) "7bit")' の
    ような書き方がされています.

ちなみに, flim-1_14-rfc2231 では `default-encoding' をこっそりと廃止して
あったのですが, 問題があるという報告は出ていません;-)


FLIM-API.en には他にも気になる点がありますが, とりあえずここまで.
-- 
Shuhei KOBAYASHI