[ruby-dev:40486] Re: [ruby-cvs:33954] Ruby:r26739 (trunk): * ext/openssl/ossl_digest.c (GetDigestPtr): Allow to pass the

2010/2/24 Akinori MUSHA <[e-mail]>:
>> 暗号処理の分野では、Mac is-a MessageDigestは成り立たないので、サブク
>> ラス化に反対する予定です。できればDigest（非OpenSSL版）も戻したい。
>
> 　そういえば ruby_1_8 にバックポートせずに trunk に置いたまま、
> いつか議論しようと思っているうちに 1.9.1 が出てしまったのでした。

HMACのDigestのサブクラスとしての追加について、2006年にIRCでそのような話していたのですが、結局私がruby-devに出て行かなかったのが原因でした（
http://gist.github.com/314485）。すいません。私はまだ真面目に1.9を使ってないということですが（状況説明:
HMAC追加は1.9から）。

というわけで、3年経って出てきました。

> 私の主眼は実装の共有にあるのですが、どのようなモジュール構成が
> いいと思いますか？

1 まず実装共有の可能性について。以下、現在Digest::Instanceに実装されている機能について取り上げます。他の共有であれば指摘してください。

1.1 値をhex、base64で取り出す、という実装の共有可能性については、アリだと思います。

1.2 update/reset/dup/to_s/inspect/==/sizeについては、ハッシュ化、署名について、可能だと思います。長いストリームデータを入力とし、比較的短いデータ（ストリーム扱いする必要のないもの）を取り出す、状態を持つ変換器用のフレームワークですね。

1.3 ちなみにもう少し拡張してfinishを追加すると、暗号化、Zlib、CSV、Base64など、出力も長いストリームな場合に対応できますが、話を広げすぎると混乱するのでやめておいたほうがよいと思います（話題を絞る）。

2 次にどのようなモジュール構成がよいかですが、

2.1 hex、base64については、正直pack一発という話なので、これだけだったらモジュール分離して構成考えてやるうまみはなさそうです。

2.2 こちらについては、ハッシュ化、署名に依存しない話なので、「長いストリームデータを入力とし、比較的短いデータ（ストリーム扱いする必要のないもの）を取り出す、状態を持つ変換器用のフレームワーク」にうまく名前をつけて、lib直下に置くのがよいと思います。名前のアイデアはないのですが、どなたかよその分野とかで使われている用語などご存知ないでしょうか。で、hmacもlib直下において、それとdigestに依存する、と。

ちなみにcrc32も、Zlibに追加すべきではなく、hmac同様lib直下がいいでしょう。実装はzlib使ったままでいけると思います。

3 雑談

3.1 JRubyのを実装した経験からすると、Digest::InstanceはRubyのままがよかった。。。読み解くの大変でした。

3.2 Javaの標準添付ライブラリを素直なまま利用してると、Zlibとcrc32のdupが実装できません（JRubyのzlibモジュールの話）。ので、dupはなくなるとうれしい。冗談ですけど。みなさん使いますかdup？

以上です。