top / index / prev / next / target / source

2005-02-25 diary: OpenOffice.org SDKへの道のり , KNOPPIX+Webサーバでクラック耐性運用が可能に

いがぴょんの日記 日記形式でつづる いがぴょんコラム ウェブページです。

old-v2

OpenOffice.org SDKへの道のり , KNOPPIX+Webサーバでクラック耐性運用が可能に

残念なことに、私の利用目的の範囲において、Jakarta POI も JExcelApiも 正常に動作しない場合がありました (主に書き込み系)

Jakarta POI も JExcelApiも、私の利用目的では正常に動作しない場合がありました → OpenOffice.org SDKへの道のり

残念なことに、私の利用目的の範囲において、Jakarta POI も JExcelApiも正常に動作しない場合がありました。これは主に書き込み系における問題です。双方とも 良くできたライブラリだけに惜しいです。POIの方は ソースコードを見て何とか動作を改善できないかと 少しだけ頑張ってみましたが、私の手には負えませんでした。JExcelApiは Biffに関するクラスも設計されているので、あるいは、とも思うのですが、時間切れ＋根気切れで断念しました。OLEのシリアライズ・デシリアライズとかなので、片手間でのコントリビュートは無理です。OLEの該当箇所のストリームをオブジェクトにマッピングせずにそのまんま保持していれば、あるいは、というところなのですけれどもね。そうなってくると そもそもの設計方針と関連がありまして、ちょいでは手が出せませんでした。

ここで JooConverterに携わっていた経験と記憶が結びつきます。ぴぴぴって感じです。そうです。Excel入出力については、OpenOffice.org SDK経由による *.xlsファイル入出力が 既に現実的に利用可能なレベルまで到達しているのです。ああ…。これでようやく、世の有識者の方々が OpenOffice.org SDK に手を出している理由が分かってきました。OpenOffice.org SDK経由による Officeファイルの入出力という方式が、最も現実的で妥当な最適解だったのですね。…私 どうしても自分の手で確認しないと気が済まないタチなのでしょう。有識者の方々がOpenOffice.org SDKにたどり着くまでの道のりを、やっぱり今回も追体験してしまっています。効率は少し悪いです。しかし正確な判断を下すためにはこういった追体験という作業も、必要なプロセスでもあるように考えます。

ということで、今後は OpenOffice.org SDKに この手のツール系API資源を集中して投入していこうと思います。OpenOffice.org SDK は APIの取っつきが非常に悪いですが、それを遙かに超える有益性があります。なによりも 一回ラッパークラスを作成してやれば、だれでも利用可能になるでしょうから。また、それはJooConverterによって実現可能性ははっきりと証明されています。

関連する日記

アイデアメモ: KNOPPIX+Webサーバで、クラック耐性の強いサーバ運用が可能に

ふと思いつきました。KNOPPIX+Webサーバの組み合わせで、外部からの攻撃(内容改ざんのこころみなど)に耐性の強いサーバが構築できるように考えました。 CD-RWから起動すれば、内容の書きかえは基本的に不可能です。何といっても、リードオンリーでドライブをマウントしているのですもの。CD-RWに入っているOSも、そもそもアタックできません。またWeb以外に Webアプリケーションサーバ+プログラムも入れておき、RDBMSは別サーバというのも、堅牢でバージョン管理が徹底できます。

このアイデアを採用するには、下記のようなハードルがあります

ただ、これは 比較的一般的な手法あるいはツールを利用して克服可能でしょうから、このアイデアは比較的簡単に導入できます。そしてなによりも、OSからコンテンツから一式がCD-RW (場合により DVD-RW)に入っていますから、OSが壊れて起動できなくなるというトラブルがまず無く、運用コストの面からとても魅力的である点です。

blancoDb .NET generator

ふと昨日 当初のblancoDb検討段階において blancoDb に .NET用のソースコードを吐き出させるとう機能を思い出しました。いわば「blancoDb .NET generator」ですね。基本的に blancoDbなのだけれども、生成するソースコードが C#.NET用のソースコードということになります。(その際も blancoDbはJavaで書かれます)

ADO.NET とか ODP.NETのAPIの特徴 (統一感のなさ)を blancoDb .NET generatorが埋めて、しかも R/Oマッピングを行ってやって生産性を向上するというのが狙いです。

世間のニュースから

この日記について