原來AJAX是….

(source: brajeshwar)

某清潔劑品牌啊~~

好，說正經的，ajax可以說是今年的最in話題，結合了 css, javascript, http headerRequest，現在一般的html網頁也可以做到某些RIA的功能，而市場上也出現幾個相關的library，其中最讓我印象深刻的是下面兩家：

-bindows:這家的library API寫的非常清楚，簡單易用，而且整個windowing system & widgets 都做的很齊全，只要玩一下他們的samples就會發現這確實是很偉大的成就。

-backbase:這家是比較晚出來的公司，也是提供現成的library，只要操作它的API就會自動生成對應的 css/javascript，但它不支援mac系統，以我現在寫文章用的 os x safari來說，連上去就會被導入特製的頁面，上面大大的紅字寫者：
Your web browser is not compatible with the primary Backbase site.

相對比起來，flash因為使用共通的vm，因此在cross-platform方面的表現是比較另人安心的。

另外一個有趣的現像是，現在RIA這個字似乎已成為顯學，各方技術都打上這個名號，似乎只要有活潑一點的操作介面，或是有比較即時的資料傳輸功能，就可以稱為RIA了，這點實在讓一則以喜，一則以憂。

喜的部份是，兩三年前當macromedia開始首推這個概念與名詞時，那時並沒有太多人知道 rich application, rich client, rich media的概念，在市場上要花很多時間跟客戶解釋為何要放棄他們原本在使用的[insert your favorite tech name here, ie: asp, .net, jsp...]東西，而改用flash。

當時也必需秀大量的範例網站來增強客戶的信心，例如旅館訂房，線上基金操作、股票線圖等。而今RIA這名詞處處可見，大部份做IT的人也都略有概念，因此解釋起來就省事不少，接受度也自然提高。加上像微軟等大廠也加入宣傳的行列，因此自然接受度就更高。

憂的部份則是，RIA這個名詞的獨特性逐漸消失，兩年前如果你打者RIA的名號，大家大概知道你們是搞flash程式的公司，但現今使用這個名稱，內行一點可能就會問：你們是採取那一種技術？ajax ? xml ? flash ?

更麻煩的是，接者而來的就是比較的問題，例如：

-那ajax 跟 flash ria 有什麼不同？(答案是：差距可大了，但你必需給我二十分鐘，坐下來聽完整場簡報才會徹底瞭解)

-你們為什麼不用 xml寫介面(答案是：可以啊，如果專案規模夠大，我們也很樂意用macromedia flex去製作專案，只是現實生活中成交的可能性實在太低，畢竟一套四五十萬台幣的flex是很少客戶能負擔的起地)

不過其實產業就是這個樣子，像約十年前大家還在用33k modem上網而isp在拼命鼓吹 56k modem，那時我曾擔心，如果越多人用56k modem, 那原本就不足的頻寬會更快被吃光，可是後來想想，這是雞生蛋蛋生雞的問題，只要換個角度想， 越多人用56k modem上網，就會促使isp業者更積極的拓展頻寬，到時大家有更大的水管可以用，反而受惠，而後來事實証明，越多人上網，isp拓展頻寬的速度就越快，像現在台灣有四百八十萬用戶用adsl上網，而台灣也有者史無前例的超大連外頻寬。

同樣的情況也可以套用在ria身上，越多廠商、技術跳進來支援RIA(不管用什麼手法達成)，就可以提高客戶的需求門檻，畢竟看過bindows或flickr介面的客戶，怎能繼續忍受一成不變的傳統html網頁，這時ria slide-in 的時間點就出現了。

pda 的另類應用

早上吃早餐時cnn正好在報導美國一家喪葬業者推出的科技產品，畫面上是服務人員拿者pda(附帶一提：當畫面拉近時仔細一看才發現原來用的是 HP 4700，果然是耐操好用真正好機啊~)帶客戶走在墓園中，介紹那些墓位還沒賣出，或是每個墓位的細節。

請看下圖：

下面這張是再 zoom-in 後的畫面

透過一台pda, 加上該公司自製的 memory GIS + GPS module, 客服人員就可以很精準的在墓園中找到需要的墓位，並且輕輕點選就可以顯示每個墓位的主人、購買日期、金額、週圍是否有親人墓位、紀念圖像等。

總的來說，這樣的技術其實並不會太因難，GPS, GIS等技術與圖資早就很成熟，撰寫 pda程式或與 gps module整合也早就進入「公板」時代，只要買了相關library回來就可以快速完成，因此這則新聞吸引人的地方是什麼呢？

兩點：

1、雖然畫面中的地圖是用java做成的，但同樣的東西用flash也可以輕鬆完成，類似的地圖技術也可以用在訂位系統(例如年代售票系統的選位畫面)或圖書館的架位管理或大型停車場的車位管理，而用flash做可能的好處則包括了：

資料量可能更小(向量線條構圖加上程式的footprint本身就較小)

地圖可無限縮放(同樣還是向量繪圖帶來的好處)

網路整合更方便

可輕易加上影音功能(類似線上掃墓之類的事…)

2、cnn為這則新聞下的 tag line是：

technology brings new life to a century business.

科技為一個百年歷史的產業帶來了新生命。

這確實是很有趣的觀察，那其它產業是否也有同樣翻兩翻的機會？

理論上，當連線頻寬不再是pda的罩門時，在這個平台上可以做的事與發揮的潛力就大大的增加，確實是值得觀察的市場，相對的，手機則仍然是一個前途未定的平台，一方面 flashlite本身不夠成熟，二方面目前看到的3G費率仍然是可笑的驚人，很難找出一個足以殺出血路的niche market.

如何開啟、播放 FLV 檔案

一般來說 flv是無法直接播放，它只能透過：

1、flashcom server串流播放

2、寫一個flash player以假的 net connection跟 net stream去播放本地端的flv檔案

因此有人寫了一個小程式方便大家做 2 這件事。

rivavx flv player

rivavx 是一家專做各種 flv related business 公司，例如 authoring tool, presentation product等，但他們很熱血的免費提供了 rivavx encoder與 rivavx flv player供大家使用。

下載回去後只要將flv 拖放到player上就可以播放了。根據過去一年來的使用經驗，75%的flv它都可以順利播放。

另外上面的link也包含了免費的 flv encoder，可以將 mpg, avi 等檔案轉換為 flv, 它內部採用的是 FFmpeg 與 LAME codec，所以是完全免費的。

提到 FFMpeg順便說一下，最近似乎流行 podcatsting風，有些玩家想用flash做 podcasting player但又苦於 32k sample rate問題無法解決，這件事在server端可以很輕鬆的用一個middleware 搭配 FFMpeg 將聲音檔轉換為正確的mp3格式再餵給flash 即可，不過我沒什麼動力做這樣的事就是了 :p

BREW 的全名

Binary Runtime Environment for Wireless® (BREW)

有人想到miles davis的 bitch’s brew嗎？

附帶一提，這年頭runtime真是大行其道，.net 裏面有 Common Language Runtime (CLR)做的也是類似的事情，不論你用 C/C++/C#/VB/Java寫的程式，最後都是變成IL送進CLR執行，因此.net可兼容各家(但效能好不好穩定性高不高就再討論)，並且理論上只要有人願意做porting的苦工，.net 也能在linux, mac等各平台上執行，mono project就是一例。

因此，如果QualComm有本事把BREW做大，吸引一堆手機、pda、各種其它千奇百怪手持行動裝置廠商投入支援內建BREW，那到也算是功德一件，這樣將來不論你是用 c/c++/c#/vb/java/actionscript寫的程式，經過編譯後就能在BREW上執行，等於立刻打開全球市場，聽起來是不是很不錯呢？

Macromedia 與 Qualcomm合作共推BREW平台

一圖抵萬言

edit:許多朋有問我這張圖到底代表了什麼？請注意看右邊紅色的那塊，BREW一旦偵測到user需要JVM，就會下載一個 JVM for BREW，同樣的道理，日後支援 Flashlite 也是先偵測後下載，以此類推日後BREW想支援任何新平台都可以用這種方式插進原本的系統。

我花了點時間才搞清楚BREW的角色，上面這張圖大略就是最好的說明。

簡單講，BREW本身是個plateform，有內建幾項常見功能，但重要的是它本身其實也是一個Virtual Machine，開發者用任何語言寫成的程式經過轉換後都可以在BREW平台上執行(當然效能是另一回事)。

也因此，BREW可以宣稱與Java相容(支援J2ME/MIDP)，因為他找了家廠商寫了一個 Java VM for BREW，就我看來等於是 BREW VM上面再加一個 Java VM，也就是說當你要用一支java app時：

-原本如果手機支援 java, 就是直接下載並在java vm上跑 。

-如果你是BREW手機，app下載後先透過 Java VM for BREW編譯成 BREW格式的程式碼，然後在 BREW VM上跑。

透過相同的原理，QualComm理論上可以通吃所有常見的技術平台，包括 Flash在內。

這次的合作案看起來進行模式會很清楚，Macromedia將會寫一個 Flashlite VM for BREW (別忘了Flash Player本質上一直就是一個VM，而且是真正能做到 write once use anywhere的那種)，日後用家下載了flashlite程式時，執行情境同上：

-原本手機如果內建支援flashlite player, 就直接在flashlite VM上跑這支程式。

-如果是BREW手機，則是先將程式透過 flashlite for BREW編譯成 BREW的程式碼，然後在BREW上執行。

這個合作目前看起來對大家都有益，怎麼說呢？

-對Macromedia而言，目前支援flashlite的機子實在不多，因此如果有機會借BREW的市佔率讓flashlite可在更多手機上執行，這對打開flashlite的採用度絕對是有正面助益的。

-對QualComm而言，做為BREW平台的開發者，當然要想辦法支援最popular的平台(這樣總比苦行僧式的自已拉開發者用它的SDK寫原生程式快多了)，從它擁抱Java的做法就可看出一二，而flash目前可說是RIA 中最有潛力的選項之一，也擁有驚人數量的開發者，因此簽下合約讓flashlite可在BREW手機上執行當然是有益無害。

-對開發者而言，原本大家選用一種技術後，就會死心不再看其它平台(搞不好還暗地裏希望其它競爭平台早死早好…)，例如用java開發遊戲的廠商，很少還有餘力再開發一個flashlite版本(除非它是另一個超級瑪莉)，這中間就形成了一種面對面的競爭態勢，但現在有了BREW這種 meta-platform一切就改觀了，因為不論是java, flashlite, C, C++都可以在這個平台上共生，這時所有廠商比較能朝良性面競爭，不但不會希望其它競爭對手快快消失，反而會希望大家多寫一點產品出來儘量把BREW搞大，最好所有的手機都支援這個平台，這樣大家都有飯吃(你知道的，這就是簡單的 蛋生雞/雞生蛋 的遊戲，當app越多時用戶採用的意願就越高，而用戶數越多廠商投入開發的意願也就越大)

從這幾個面向觀察就可以知道，這筆合作案還滿有看頭的，期望生命值也比adobe合併案高一點，這怎麼看都知道就是macromedia貫有的vision與手法，實在漂亮啊~

現在就只等flashlite 儘快支援 Actionscript 2並且希望能搭上 flash player 8內建VP7 video codec的順風車，這樣手機這塊市場就開始值得多瞧兩眼了。

其它幾個觀察心得如下：

1、看完BREW的簡介第一頁，直覺就想到這是i-mode的美國版，手法幾乎一樣，有BREW專屬操作介面的手機硬體、BREW專屬的UI介面(要看成是OS也可以)、整套的交易與金流機制。

2、跟 i-mode 不同的地方在於：

-i-mode是一家獨大式的經營手法，NTT docomo並沒有授權其它電信廠商採用i-mode的server端設備

-i-mode沒有兼容各平台的野心與服務，相反的，他的創辦人在書中明確指出i-mode一向以採用市場主流技術為主，例如 html等，它絕不會費心去搞一個 Java for i-mode

-i-mode的應用似乎以資訊交換(網頁、新聞、video簡訊)為主，不常見到有vendor寫了app拿上去賣，而這是BREW主打的強項之一。

所以目前的感覺是BREW應該從 i-mode吸收了不少經驗，然後強化某些功能兼容最大公約數的市場，他玩的規模與野心都比i-mode大了不少，只是不知道成功率是否會那麼高。

最後，我的疑慮是，VM on VM 的執行效能到底表現如何？一般來說用一層VM速度就已經degrade不少，如果再疊一層上去，那….

當然或許BREW是從AISC chip level就結合，因此它的操作比較底層，對效能的影響比較小，但 java for brew 與 flashlite for brew的表現恐怕就不這麼樂觀了。

final note: QualComm這家公司我一直非常熟悉，主因是十年來我都用他們出品的 Eudora做為主要的mail program，真是沒想到他們在其它領域的表現也如此出色。不過可惜的是隨者我即將全面轉換到 mac 平台，以即thunderbird之類的程式表現也挺出色，讓eudora下台一鞠恭的時日已經不遠了。