ALPを支えられなかった技術(2)

ALP第二期 - LIMOを狙って

便宜的に分けた ALPの第二期は LiMo を巡る動きとなります。

とはいうものの、この期の分け方は適当で、実際には複数のプロジェクトが同時に走っていて、 GTkをつかった第一期のプロジェクトと LiMoむけの第二期は社内でも平行して走っていました。自分は前者のプロジェクトにメインで関わっていたので、LiMoむけの作業はちょっと手伝っただけです。

というわけでどちらかと言うと LiMo関係については担当者の愚痴やらで伝え聞いた部分が多いのでネガティブな印象になってることは否めません。その点はなるべく割り引いて書くようにしますが。

LiMoとは

Wikipediaにあるとおり、ハンドセットメーカー 4社とキャリア2社が連携して携帯用プラットフォームを作ろう、というものでした。大同団結といえばいいけど、呉越同舟というか同床異夢な感は当時としても否めませんでした。具体的になにを作ってなにを達成しようとしてたのか、が末端エンジニアにはよくみえず、やりにくいなあ、ということは感じたものです。

やりたいこととしては、Nokiaやら Microsoftやら (まだ出荷されてなかったけど) Android や iPhoneに市場を席巻されないようにしよう、という後ろ向きの目標のようなものは感じられました。ただ、いままで別々にソフトを開発してきて、違う市場に対応してきた各社があつまって意味のあるものを作り上げられるようには見えませんでした。

LiMoは APIでしかない

今から考えてみると LiMoとは TRON、もしくは POSIXのようなものだったのでしょう。あくまで APIを一致させ、その上で共通アプリケーションを作り上げられるという。 APIを一致させておけば、アプリケーションとミドルウェアの組み合わせは選べるという。というわけで、ACCESSが ALPをベースにして作り上げたものは「リファレンス実装」という位置づけになります。

とはいうものの、世の中はそんな絵空事どおりに動きません。 APIだけでは依存関係を解決することはできず、そこから派生したエコシステムやらがひっついて回るのが必定です。 Windowsの POSIXサブシステムがあったって、世に多く普及している Linuxやらのアプリケーションは動きません。

ましてや、まだアプリケーションもない LiMoのことです。ハンドセットメーカー各社に、共通の LiMoのAPIだけをつかってアプリケーションを書くモチベーションがあったか疑問です。また、それ以外のプレイヤーがアプリケーションを書いて流通させるチャンスがあったかもよくわかりません。

ACCESSの作ったリファレンス実装

ACCESSはそのような動きの中で、ALPと、すでにあたった Docomoの Linuxプラットフォームを合わせてリファレンス実装をつくることになりました。ここらへん、ACCESS以外の各社の IPに関することにもなるので、いろいろ大変だった、とごまかさせてください。ただ、いろいろと NECの人などからガラケーのガラケーたらしめる作り込みについて話を聞けたのは面白かったです。

LiMoのまとめ

個人的見解としては、LiMoは ALPの中では傍流、DoCoMoにお付き合いするためのプロジェクトという理解です。もちろん、そこから LiMoがひろがって各社でつかわれることをもくろんでいたのかもしれませんが、そこにはいろいろと政治的なとりひきをしなければならなかったでしょう。個人的にはあまりお付き合いをしたくない分野です。

というわけで技術的な話は今回はあまりありませんでしたが、次回、Monolithのはなしまでお待ち下さい。

Snippets

対抗して作ってみた。