読者です 読者をやめる 読者になる 読者になる

Snippets

対抗して作ってみた。

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

ALPを支えられなかった技術(0) - Snippets の続きです。

ALP第二期 - LIMOを狙って

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

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

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

LiMoとは

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

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

LiMoは APIでしかない

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

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

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

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

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

LiMoのまとめ

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

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