添付譜類はあくまでも添え物として最小限の役割に留め,エクスポート機能でも実譜類の出力には今後対応しない方針を固めた。
元々添付譜類は添え物として設計しているが,実際に譜類添付機能が出来,エクスポート機能を実装しようとしてみると,実質的な役割の落とし所が意外に難しい。意図に反して,変に使われ過ぎるのも問題だ。
エクスポート機能では,とりあえずは代替 HTML などで済ませ,ゆとりが出来たら実譜類にも対応するか,などと考えていた。そもそも,どんな大企業のクラウドであれ消えて困るような譜類の唯一の保管場所にすべきではないし,そこまで神経質な人が手元に抜控を持っていないということも考えにくいので,実はさほど必要性の高い付徴ではない。とはいえ,エクスポート時の負荷や帯域だけが問題なら金で解決出来るのだから,将来的に対応しないというほどの動機もない。
しかし,添付譜類がエクスポート出来てしまうことで譜類倉庫的な利用が増え,それに伴い譜類保全の責任が増せば,将来にわたって無視出来ない経営上の問題になる。ということについさっき気付いた。描出公開原則同様,ここは割り切った用者文化を育てていくべきだろう。
これに気付いてみて,最近,添付譜類の役割を広げようとし過ぎていたことにも気付いた。譜類添付機能のサイズ上限や拡張子制限の緩和も考えていたが,これも最小限に留めることにした。拡張子制限は制危面もあるが,献典として非効率だったり無意味だったりする譜類の上信抑止といった効果も望める(例えば .bmp
をそのまま上信して欲しくはない)。
デライトの強みは,知番による意味符号化で文字献典の情報密度を極限まで高め,その軽さを最大限に活かせることだ。譜類倉庫的な方面で消耗するのは差別化戦略として明らかに悪手だ。譜類添付機能実装以降,その軸が微妙に揺らいでいることはうっすら感じていた。今日は妙に頭がもやもやしていると思ったら,どうも脳がそれを訴えていたらしい。気付いたら非常にすっきりした。
描出公開原則のように何かこの方針に名前を付けたくなったが,「譜類添付機能」という名前で趣旨は表現出来ているので,それに立ち返るということで十分だろう。