<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>d.CAT- the RIA blog &#187; other-tech</title>
	<atom:link href="http://ria.richtechmedia.com/category/other-tech/feed/" rel="self" type="application/rss+xml" />
	<link>http://ria.richtechmedia.com</link>
	<description>a dedicated Flash&#124;Flex Rich Internet Application Blog from a senior Flex RIA developer/instructor</description>
	<lastBuildDate>Wed, 07 Apr 2010 02:39:40 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>原來AJAX是&#8230;.</title>
		<link>http://ria.richtechmedia.com/2005/07/22/ajax/</link>
		<comments>http://ria.richtechmedia.com/2005/07/22/ajax/#comments</comments>
		<pubDate>Fri, 22 Jul 2005 00:11:56 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[flash]]></category>
		<category><![CDATA[other-tech]]></category>

		<guid isPermaLink="false">/?p=180</guid>
		<description><![CDATA[
(source: brajeshwar)
某清潔劑品牌啊~~
好，說正經的，ajax可以說是今年的最in話題，結合了 css, javascript, http headerRequest，現在一般的html網頁也可以做到某些RIA的功能，而市場上也出現幾個相關的library，其中最讓我印象深刻的是下面兩家：
-bindows:這家的library API寫的非常清楚，簡單易用，而且整個windowing system &#038; 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 [...]]]></description>
		<wfw:commentRss>http://ria.richtechmedia.com/2005/07/22/ajax/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>pda 的另類應用</title>
		<link>http://ria.richtechmedia.com/2005/07/19/pda/</link>
		<comments>http://ria.richtechmedia.com/2005/07/19/pda/#comments</comments>
		<pubDate>Tue, 19 Jul 2005 02:13:17 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[flash]]></category>
		<category><![CDATA[other-tech]]></category>

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

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

透過一台pda, 加上該公司自製的 memory GIS + GPS module, 客服人員就可以很精準的在墓園中找到需要的墓位，並且輕輕點選就可以顯示每個墓位的主人、購買日期、金額、週圍是否有親人墓位、紀念圖像等。
總的來說，這樣的技術其實並不會太因難，GPS, GIS等技術與圖資早就很成熟，撰寫 pda程式或與 gps module整合也早就進入「公板」時代，只要買了相關library回來就可以快速完成，因此這則新聞吸引人的地方是什麼呢？
兩點：
1、雖然畫面中的地圖是用java做成的，但同樣的東西用flash也可以輕鬆完成，類似的地圖技術也可以用在訂位系統(例如年代售票系統的選位畫面)或圖書館的架位管理或大型停車場的車位管理，而用flash做可能的好處則包括了：
資料量可能更小(向量線條構圖加上程式的footprint本身就較小)
地圖可無限縮放(同樣還是向量繪圖帶來的好處)
網路整合更方便
可輕易加上影音功能(類似線上掃墓之類的事&#8230;)
2、cnn為這則新聞下的 tag line是：
technology brings new life to a century business.
科技為一個百年歷史的產業帶來了新生命。
這確實是很有趣的觀察，那其它產業是否也有同樣翻兩翻的機會？
理論上，當連線頻寬不再是pda的罩門時，在這個平台上可以做的事與發揮的潛力就大大的增加，確實是值得觀察的市場，相對的，手機則仍然是一個前途未定的平台，一方面 flashlite本身不夠成熟，二方面目前看到的3G費率仍然是可笑的驚人，很難找出一個足以殺出血路的niche market.
]]></description>
		<wfw:commentRss>http://ria.richtechmedia.com/2005/07/19/pda/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>如何開啟、播放 FLV 檔案</title>
		<link>http://ria.richtechmedia.com/2005/06/07/flv/</link>
		<comments>http://ria.richtechmedia.com/2005/06/07/flv/#comments</comments>
		<pubDate>Tue, 07 Jun 2005 03:13:11 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[flash]]></category>
		<category><![CDATA[other-tech]]></category>

		<guid isPermaLink="false">/?p=156</guid>
		<description><![CDATA[一般來說 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
]]></description>
		<wfw:commentRss>http://ria.richtechmedia.com/2005/06/07/flv/feed/</wfw:commentRss>
		<slash:comments>5</slash:comments>
		</item>
		<item>
		<title>BREW 的全名</title>
		<link>http://ria.richtechmedia.com/2005/06/04/brew/</link>
		<comments>http://ria.richtechmedia.com/2005/06/04/brew/#comments</comments>
		<pubDate>Fri, 03 Jun 2005 17:28:36 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[flash]]></category>
		<category><![CDATA[other-tech]]></category>

		<guid isPermaLink="false">/?p=150</guid>
		<description><![CDATA[ Binary Runtime Environment for Wireless® (BREW)
有人想到miles davis的 bitch&#8217;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上執行，等於立刻打開全球市場，聽起來是不是很不錯呢？  
]]></description>
		<wfw:commentRss>http://ria.richtechmedia.com/2005/06/04/brew/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Macromedia 與 Qualcomm合作共推BREW平台</title>
		<link>http://ria.richtechmedia.com/2005/06/04/macromedia-qualcommbrew/</link>
		<comments>http://ria.richtechmedia.com/2005/06/04/macromedia-qualcommbrew/#comments</comments>
		<pubDate>Fri, 03 Jun 2005 17:10:17 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[flash]]></category>
		<category><![CDATA[other-tech]]></category>

		<guid isPermaLink="false">/?p=149</guid>
		<description><![CDATA[
一圖抵萬言
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手機上執行當然是有益無害。
-對開發者而言，原本大家選用一種技術後，就會死心不再看其它平台(搞不好還暗地裏希望其它競爭平台早死早好&#8230;)，例如用java開發遊戲的廠商，很少還有餘力再開發一個flashlite版本(除非它是另一個超級瑪莉)，這中間就形成了一種面對面的競爭態勢，但現在有了BREW這種 meta-platform一切就改觀了，因為不論是java, flashlite, C, C++都可以在這個平台上共生，這時所有廠商比較能朝良性面競爭，不但不會希望其它競爭對手快快消失，反而會希望大家多寫一點產品出來儘量把BREW搞大，最好所有的手機都支援這個平台，這樣大家都有飯吃(你知道的，這就是簡單的 蛋生雞/雞生蛋 的遊戲，當app越多時用戶採用的意願就越高，而用戶數越多廠商投入開發的意願也就越大)
從這幾個面向觀察就可以知道，這筆合作案還滿有看頭的，期望生命值也比adobe合併案高一點，這怎麼看都知道就是macromedia貫有的vision與手法，實在漂亮啊~
現在就只等flashlite 儘快支援 Actionscript 2並且希望能搭上 [...]]]></description>
		<wfw:commentRss>http://ria.richtechmedia.com/2005/06/04/macromedia-qualcommbrew/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>podcasting buzz</title>
		<link>http://ria.richtechmedia.com/2005/05/19/podcasting-buzz/</link>
		<comments>http://ria.richtechmedia.com/2005/05/19/podcasting-buzz/#comments</comments>
		<pubDate>Thu, 19 May 2005 04:09:30 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[other-tech]]></category>
		<category><![CDATA[tech-news]]></category>

		<guid isPermaLink="false">/?p=146</guid>
		<description><![CDATA[昨天貼了 mediatuner這個小軟體後，看了一下它的spec，結果提到一個 podcasting的字眼兒，原先以為這是某種ipod的延伸產品或服務，經過小小調查得到以下結果：
wiki的解釋
介紹1
介紹2
簡單說明：
其實這根本不是什麼新玩意，就跟大家之前把音樂檔放上blog給人聽或下載，或是像自架server做廣播(例如pushpush.org推推音樂網)，唯一的不同只在於它結合 rss 2.0可享受到所有 rss的好處。
因此 mediatuner這個軟體可以說是一個 podcasting reader，它除了可以讀 text blog外，也可以收聽 podcasting裏面播放的audio檔案。
我的疑問只有一個：
在自已的站台上放龐大的audio檔案供人下載，請問頻寬成本誰要付？
目前身邊朋友有在玩 個人廣播 的，通常都有辦法找到免錢的大水管架server，例如朋友正好在isp上班，或某學校的免錢機器，因此 個人 只要將訊號送進這台server，其餘的聽眾都是跟那台server要audio，這樣不論多少人都能應付的了。
但 podcasting的玩法卻是把audio檔放在自已的server上，例如你租的空間(通常會有數千Gb的流量限制)，如果不幸真的人聲濎沸萬頭鑽動，每個人下載一首歌就是4mb，1000人下載你這個月頻寬就爆了，而這還只是一首歌，並且限定每次只下載一次(如果我在公司抓一次，家裏抓一次，咖啡館上網時用notebook再抓一次&#8230;.呼呼呼)
這裏面怎麼想都有些也方不對勁啊~
不過看來 blogger創辦人到是很有信心，他把blogger賣掉後弄了個新公司 odeo.com 準備搭上這股 podcasting風，還上了 NY times(要登入會員才能閱讀)。
我對他創辦blogger的眼光是很配服，但不知他是否也有認知到 text content 與 audio content 的根本差異性，還有產製這些內容的技術需求是完全不同的啊，畢竟買ipod只要會掏錢或信用卡就好，但要做 digital audio recording/editing/publishing就不是兩三句話的功夫了。
]]></description>
		<wfw:commentRss>http://ria.richtechmedia.com/2005/05/19/podcasting-buzz/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>longhorn clone 介面</title>
		<link>http://ria.richtechmedia.com/2005/04/26/longhorn-clone/</link>
		<comments>http://ria.richtechmedia.com/2005/04/26/longhorn-clone/#comments</comments>
		<pubDate>Mon, 25 Apr 2005 18:01:56 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[mac/OS X]]></category>
		<category><![CDATA[other-tech]]></category>

		<guid isPermaLink="false">/?p=132</guid>
		<description><![CDATA[
下載
note:這是一個windows shell pack，會完全改變你的視窗外觀(顏色、造型、icon等)
看起來跟蘋果大貓像的神奇啊~
如果是這樣，那還是真的比較好 :p
由這點可以得到幾個不負責結論：
1、aqua式的task bar(可游移放大縮小)將成顯學，雖然我覺得三層式的比較讚
2、放大toolbar的圖像並且一律採用半透明反光式設計也將成為標準
3、刷淡 titlebar 與 toolbar間的分隔並縮小右上方的控制鍵也成為潮流
所以，更簡單的結論是：大家直接去下載一本免錢的 Apple GUI guide然後銘記在心即可~
]]></description>
		<wfw:commentRss>http://ria.richtechmedia.com/2005/04/26/longhorn-clone/feed/</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
		<item>
		<title>bsd各版本小註解</title>
		<link>http://ria.richtechmedia.com/2005/04/09/bsd/</link>
		<comments>http://ria.richtechmedia.com/2005/04/09/bsd/#comments</comments>
		<pubDate>Sat, 09 Apr 2005 09:26:22 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[other-tech]]></category>

		<guid isPermaLink="false">/?p=117</guid>
		<description><![CDATA[最近剛搬完家，忙了兩星期終於可以回到桌前專心工作了。
今天開始要重裝一些系統，順便翻了幾本關於bsd的書，將心得速記如下。
1、AT&#038;T Unix 是最早的unix，後來傳到西岸berkley產生了 BSD 版本(Berkley System Distribution)
2、有人將BSD移植到可在個人電腦(386處理器)上執行，名為 386/BSD，從unix脫離高檔昂貴大型主機的世界。
3、386BSD之後衍生出許多類似的版本，例如FreeBSD, NetBSD, OpenBSD&#8230;.
4-1、FreeBSD以最穩定著稱，許多isp都愛用
4-2、NetBSD相容性最高，幾乎各種裝置、平台都可執行，有人曾經笑稱乾脆在鬧鐘或鉛筆盒裏也裝一個NetBSD
4-3、OpenBSD號稱最安全，其網站上之tagline為: 八年來只發現一個hole。
5、但BSD不是唯一可在386個人電腦上執行的unix系統，其它如Solaris, Darwin等也都已port到pc上了。Solaris最近也採open source策略希望可捥回生機，而最近火紅的mac os x則是以 darwin為基礎，這個darwin也是386BSD的分支之一，但其採用的kernel為Mach，所以簡單來說不論 xxxBSD, solaris, darwin等都是unix系列的一種，基本上指令、程式都是相容的。
6、從發展的血源關系來看，BSD系是走比較正統的unix路線，而linux系列則是另起爐竈仿效unix寫出的系統，因此不理性的推估是BSD應該會比linux穩定、安全一點，但易用度、親和性就不見得那麼高。
7、基於上述的歷史發展與考量，很多人還是愛用FreeBSD做為server的作業系統，這也是為什麼我現在正努力安裝中的原因  
當然linux也沒什麼不好，接下來我會重裝redhat 跟 debian/ubuntu同時跑三個系統，開發環境也非常有可能還是在linux上，但日後會慢慢轉移到FreeBSD。
]]></description>
		<wfw:commentRss>http://ria.richtechmedia.com/2005/04/09/bsd/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>C#的命名由來</title>
		<link>http://ria.richtechmedia.com/2005/03/29/c/</link>
		<comments>http://ria.richtechmedia.com/2005/03/29/c/#comments</comments>
		<pubDate>Mon, 28 Mar 2005 18:13:29 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[other-tech]]></category>

		<guid isPermaLink="false">/?p=113</guid>
		<description><![CDATA[C -> C++ -> C++++
但 C++++太長，就變成 C#     
這是今晚聽朋友講的，據她說千真萬確真有其事  orz.
但我到這裏查了一下並沒有收穫。
]]></description>
		<wfw:commentRss>http://ria.richtechmedia.com/2005/03/29/c/feed/</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
		<item>
		<title>persistent layer 第二擊</title>
		<link>http://ria.richtechmedia.com/2005/03/21/persistent-layer/</link>
		<comments>http://ria.richtechmedia.com/2005/03/21/persistent-layer/#comments</comments>
		<pubDate>Sun, 20 Mar 2005 16:31:34 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[actionscript]]></category>
		<category><![CDATA[other-tech]]></category>

		<guid isPermaLink="false">/?p=102</guid>
		<description><![CDATA[因為是懶人，所以尋找能順利將object < -> database 轉換的framework就一直是high priority task，
尤其是那些可能可以跟actionscript搭在一起合作愉快的方案更是吸引人。
當然如果你很忙沒時間繼續看下去，那先知道結論就好：目前沒有一個可以直接跟flash配合。
當然由於flash的工程師user base太小，一開始我也不指望會有這種東西，因此直接是從.net與java下手看能不能改過來用。
最初我找到一些關於 O/R mapping的書與文章，裏面教授的是過去二十年來工程師們一直用的手法(也就是雙手萬能的手工藝技巧)，而其中最令我心驚膽顫的一句話就是：
as stated before, 40-60% of the project time were used to handle OR mapping
當然手工藝並不是真的那麼萬惡不赦，很多中小型的案子自已動手或許真的比較快。
但由於類似O/R mapping這樣每天都得處理的routine實在是很煩索的可以，因此java界開始出現一個名為Java Data Object (JDO)的概念，也就是提供一個object 與 database的中介層，這原本只是sun提出的一個spec，但由於很受歡迎，因此很快市場上就出現一狗票的實作商品，理論上可以讓工程師完全不用再手動處理O/R mapping這件事。在所有的JDO-alike的實作裏，OJB算是open source圈內最響叮噹的一個方案。
而這幾年從JDO的概念又衍生出一個更新的persistent 技術，叫做 Hibernate，這個字實在是用的巧妙，讓人發出會心微笑。它有趣的地方在於hibernate原本是指電腦用完但不想關機時，可以按下休眠將ram裏的東西dump到disk上暫存，下次開機時只要把資料讀回ram裏就可以迅速回到可操作狀態(當然現在大家隨便都裝1、2GB的ram，這招不見得會快很多)；而這個字用在persistent方面，很明顯的可以看出工程師是認為 Object 才是&#8221;正常的操作狀態&#8221;，而存入資料庫(或其它persistent store)只是類似休眠的動作一樣，等將來要用時再取出即可。
從這個類比就不難看出Hibernate想要達到的目標，聽起來確實非常迷人，而更棒的是這個概念已經被port到各種語言，例如C#, php等都有，而且往往還有超過一種的選擇。
以目前調查的結果來看，比較完整的hibernate port都會再包含一層 database abstract layer，讓整個流程變的更有彈性(因為連data store的目標都可以隨便更換)，因此簡單來說，只要想辦法把物件從flash丟回app server，剩下的就交給 C#/php去處理，更讚的一點在於flash remoting可以透過binary的方式傳遞 native actionscript object (例如最常用到的 numeric array與associative array)，因此只要巧妙的玩弄remoting的binary特性，就可以在某種層度上達到Java Value Object甚至某些EJB才能做到的效果。
所以未來幾天有空的時間我會試試把整個流程串起來，看看是否真的可行。
不過使用persistent framework也不是完全沒有缺點，目前已知的問題有：
1、全新的專案比較適合使用，因為通常framework會統包db [...]]]></description>
		<wfw:commentRss>http://ria.richtechmedia.com/2005/03/21/persistent-layer/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
