スライド

困ったこと

機能衝突の問題

XULアプリケーションの開発が容易であること、敷居が低いということから、（今のところ海外を中心に）非常に多数の拡張機能型XULアプリケーションが公開されています。しかしそれ故に、組み合わせによってはどちらか一方が動かなくなったり、あるいはどちらも動かなくなったりという機能衝突が起こることがけっこうあります。

また、変数名や関数名が同じといったコーディング上の問題で起こるトラブルもあります。これについては、問題の起こりにくいコーディングルールの徹底を心がけることが肝心だと思います。例えば私は、Javaなどでいうところの静的クラスのように、関数や変数をオブジェクトのメソッド・プロパティとして記述するというルールを使うことが多いです。このやり方はMozillaのブックマーク関連のコードでも使われています。

ライセンスの問題

ライセンスのことがよく分からないからXULアプリケーション開発に手を着けづらい、ということもありました。Mozilla本体のコードのライセンス自体がGPLだのMPLだのと大変ややこしいことになっています。また、個人の作成するXULアプリケーションについても、「強制オープンソース誰でもソース見放題」という特徴からソースコードを参考にしたり改造版を作成したりしやすくなっているのですが、そういった派生アプリケーションの扱いをあらかじめ明記されていないことがよくあります。

実際に、私は、他の方の作られた拡張機能がMozillaのバージョンアップで動作しなくなった際に独自に対応版を作成したことをきっかけにしてXULアプリケーション作成に関わるようになったのですが、この時にも、再配付の条件等が明らかでなかったため改造版を配布するかどうかでだいぶ悩みました。

皆さんがXULアプリケーションを作成される際には、無用のトラブルや誤解を避けるためにも、再配付を許可する場合でも全面的に禁止する場合でも配布ページにその旨を明記しておかれることをお勧めします。