關(guān)于個人文檔管理 － 電子書2

上一篇文章里面說到，手里的電子書，大體可以分成經(jīng)典、手冊、喜歡的、教材、普通的書、消遣、難懂的書、別人推薦的書、騙人的書這么幾個類別。

那么針對這幾個類別該怎么區(qū)別對待呢？

1、對于經(jīng)典的、手冊類型的書：對于這種經(jīng)常會用到，而且極有價值的書，要放到最容易獲得的地方。通常每個人的這種書都不多。把它們管理好（后面會說怎么管理）后，做一個鏈接放到桌面上或者桌面上的文件夾里。——當(dāng)然，在Mac下還有更好的方式，不過在Windows和Linux下，按上面的方式來做就足夠了

2、對于經(jīng)常喜歡看的、消遣的書：如果可能，放到手機(jī)、MP3里面吧。那樣你就什么時候都能看了。呵呵。

3、對于教材、普通的書：分門別類的管理好。給你正在看的書建個鏈接放到桌面上。看完了怎么處理后面再說

4、對于難懂的和別人推薦的書：扔掉它吧。再好的書，不看也是垃圾一堆。不要擔(dān)心你可能會有真正想讀的時候，一般來說，技術(shù)類書籍，你現(xiàn)在不想讀，你永遠(yuǎn)都不會想讀的。而且，如果是經(jīng)典的話，你想讀的時候自然會找得到。

好了。有了上面的對電子書區(qū)別對待的前提后，我們來開始討論如何在計算機(jī)上管理電子書吧。

首先，我要先說一說我認(rèn)為電子書管理中最重要的兩個前提：
1、CPU的時鐘周期不值錢，你的時間值錢。
2、硬盤的容量不值錢，你的大腦容量值錢。

有了這兩個前提，就可以說說我在電子書管理方面的經(jīng)驗啦。我的經(jīng)驗大體如下：
1、不要建立過多、過深的文件夾：
一般來說，除了該死的java程序，你的文件夾都不要建到5級以上。因為即使每個文件夾里面只有兩個文件夾，你就會有32個文件夾。你的大腦容量是有限的，你不需要記住這些文件夾的，一般人也記不住。
你終究會發(fā)現(xiàn)，為了找到一個文件，你總是在不同的文件夾中跳躍。

2、集中管理：
不要告訴我你的文檔散布在多個分區(qū)（C:、D:、E:...）的多個文件夾下。相信我，那絕對是一個噩夢。你可能會反駁我說，我把所有的雞蛋都裝到了一個籃子中，會有風(fēng)險。實際上，你只有一個文檔文件夾的話，備份和同步是一件非常容易的事情。

3、要搜，不要找：
當(dāng)你的文檔越來越多的時候，你就會發(fā)現(xiàn)在文檔文件夾里找到你想要的文檔是多么麻煩的一件事情了。現(xiàn)在的操作系統(tǒng)都有可以進(jìn)行全文檢索的高性能搜索引擎了。畢竟機(jī)器要比肉眼精確，你的時間要比CPU的時鐘周期更值錢

4、利用元數(shù)據(jù)
在這一點(diǎn)上，Mac是做得最好的。它提供了Spotlight注釋這個完美的東西。你可以以注釋的方式來為文檔添加搜索的元數(shù)據(jù)。這也是我現(xiàn)在進(jìn)行電子書管理的精髓所在。Google Desktop好像沒有這個功能。

總結(jié)一下，通過在電子書管理的兩個前提下，靈活的使用鏈接、搜索的功能。是我管理電子書的手段。

我會在下一篇文章里，說說我管理電子書的方式。

posted @ 2008-09-01 14:37 guitarpoet 閱讀(564) | 評論 (0) | 編輯 收藏

關(guān)于個人文檔管理 － 電子書

posted @ 2008-08-31 17:46 guitarpoet 閱讀(931) | 評論 (2) | 編輯 收藏

關(guān)于個人文檔管理 - 電子郵件2

這是關(guān)于電子郵件管理的最后一篇。

我的郵件管理心得大概可以分成下面幾個點(diǎn)：

1、即看即管理：收到郵件之后，如果沒有處于不可打斷的狀態(tài)下，就要立即開始處理，處理方式大概分成下面幾種
    *如果是無用的郵件，立即把它刪掉
    *如果郵件很長，或者郵件中鏈接比較多（比如訂閱的期刊），而時間有限，把郵件設(shè)置成為未讀，留待有時間的時候讀
    *如果郵件跟工作有關(guān)，而沒有時間處理，給郵件打上旗標(biāo)，留待有時間的時候處理
2、周期性管理：每天都需要整理該天的郵件（這也是務(wù)必做到當(dāng)日事，當(dāng)日畢的工作態(tài)度），處理掉未讀的和加注旗標(biāo)的。對于期刊，未必一定要讀完。加注旗標(biāo)的工作，則需要進(jìn)行工作管理了。
3、階段性梳理：在到達(dá)階段性的時間點(diǎn)時（如一個項目結(jié)項，每個月的第一天或者最后一天）。需要對這一階段內(nèi)的工作和相關(guān)材料進(jìn)行梳理。電子郵件也是其中之一。
4、善用搜索：在充分的維護(hù)元數(shù)據(jù)之后，你就會發(fā)現(xiàn)搜索的好處了。比如，在你為項目干系人建立聯(lián)系人組之后。相關(guān)時間跨度內(nèi)的項目相關(guān)的郵件一個相關(guān)查詢就足夠了。如果你的郵件客戶端支持在查詢的結(jié)果上查詢的功能。通過聯(lián)系人、主題等等信息，一般說來，找到你想找的郵件，不會非常困難。
5、保存常用的搜索：我有幾個常用的搜索，以智能文件夾的方式保存起來了。這些常用的搜索是：
    *To Read：所有的未讀郵件
    *Today：當(dāng)天收到的郵件
    *Flagged：所有加旗標(biāo)的郵件
    *Has Attachment：所有有附件的郵件
6、充分利用郵件客戶端的特色功能：有的郵件客戶端（如GMail和Apple Mail）都可以根據(jù)話題進(jìn)行郵件自動分組。GMail的類似論壇帖子的方式是更加優(yōu)雅一些。按話題自動分組郵件，可以極大的減輕利用郵件討論一件事情的負(fù)擔(dān)。尤其是在多人討論的時候。
7、充分利用郵件的處理規(guī)則：很多郵件的管理和處理都可以采用規(guī)則進(jìn)行自動化的處理。比如，可以把所有來自家里人的郵件打上綠色的標(biāo)簽。便于和工作郵件區(qū)別開來。或者把相關(guān)郵件拷貝到相關(guān)的文件夾中（GMail的對應(yīng)操作是為這個郵件打上標(biāo)簽）。
8、利用搜索引擎技術(shù)：不要用OutLook自帶的查找。那樣查找效率太低了。可以利用MSN Toolbar或者Google Desktop這種搜索工具來幫助你。我用的是Mac OSX，Spotlight已經(jīng)很好用了。

好了，關(guān)于電子郵件的管理，就說到這么多吧。下一篇里，我將會討論電子書的管理。

posted @ 2008-08-25 21:57 guitarpoet 閱讀(396) | 評論 (0) | 編輯 收藏

關(guān)于個人文檔管理 - 電子郵件

好吧，我承認(rèn)，我的上一篇文章沒有提到跟電子郵件管理相關(guān)的事情。呵呵。

無論你使用什么郵件客戶端（GMail除外，GMail屬于比較奇怪的，待會兒再提）。郵件的管理操作都可以簡單的看成是對只讀文件的操作。

郵件就是一個個的只讀郵件，你通過文件夾（可以分級——也就是文件夾套文件夾）來分類的管理它們。

你可以通過郵件的元數(shù)據(jù)（收件人、發(fā)件人、抄送、發(fā)送時間、接收時間、重要程度、是否已讀、所在郵箱、內(nèi)容。。。）來檢索、排列和查找郵件。

下面，我來列舉幾個我所見過的郵件管理方式（我在這里只列舉我所見到的方式，使用技巧打算在下一篇文章里寫）：

1、日期型：
這類的郵件管理方式，一個最大的特點(diǎn)就是每個月都建立一個新的文件夾。文件夾的名稱就是當(dāng)月的年份和月份，如2008-02。當(dāng)月收到的郵件都從收件箱中拷貝或者直接轉(zhuǎn)移到該文件夾中（這個規(guī)則應(yīng)該很好寫）。

以一天平均收到100封郵件的頻度來算（如果是普通工作郵件的話，已經(jīng)算是非常多了，以我的經(jīng)驗來說，平均一天20～50封是正常的）。在一個工作月內(nèi)，可以收到2200封郵件。在一個文件夾內(nèi)并不難管理（何況你還會刪掉一些無意義的郵件，并且還可以在這個基礎(chǔ)上進(jìn)行分組和過濾）。

如果你確實有精益求精的追求，你可以在這個文件夾下再分成工作細(xì)類。這樣看起來更漂亮。

這種管理方式很適合短期雜事很多的人（比如HR）。這種方式的優(yōu)點(diǎn)是，月底進(jìn)行個人統(tǒng)計的時候非常方便。而且做查詢也比較方便（直接用眼睛看）。

當(dāng)然，這種方式缺點(diǎn)也非常明顯。你肯定不能從一串?dāng)?shù)字上看出你這個月都干什么了（當(dāng)然你愿意在其下花力氣分成細(xì)類，這一點(diǎn)就容易一些）。對于經(jīng)常并行的進(jìn)行有時間跨度工作（比如多個項目的平臺技術(shù)支持）的人而言，這一管理方式明顯效率低下。

2、項目型：
即使是進(jìn)行項目型的管理，仍然需要通過時間來劃分郵件（為了歸檔和寫年終總結(jié)方便）。但是時間的劃分往往會比較長，比如用一季度、半年或者一年來劃分。

項目型管理的最大特點(diǎn)就是按項目分組管理郵件。舉例來說吧。

假設(shè)我是一個平臺軟件工程師，我支持著公司在廣東、山東、北京、上海這四個項目。

我會在今年（2008）的文件夾下建立四個文件夾分別是廣東電力、山東社保、北京移動、上海聯(lián)通。我會在我的聯(lián)系人里建立這四個組。然后建立四個規(guī)則，把所有在收件箱中這四個組中聯(lián)系人發(fā)的郵件分別拷貝或者移動到這四個文件夾中。

項目型的方式，適合于對多個項目（子項目）進(jìn)行并行工作的人。在項目相關(guān)的文件夾中可以通過基于時間的查詢查找到相應(yīng)的郵件。可以很一目了然的看出你在某一年都做了哪些項目。而且，通過按照時間的查詢，仍然可以查出你在某個月的工作郵件。

如果你的雜項工作很多或者大多數(shù)都是沒有規(guī)律的工作，這種方式就不一定合適。

3、區(qū)別對待型：
區(qū)別對待型的精髓，就是看人下菜碟。以我的經(jīng)驗，在營銷的人員中采用的比較多。不過也有技術(shù)人員采用。呵呵。

區(qū)別對待型就是按照聯(lián)系人的組來安排郵件。比如可以建這么幾個文件夾：領(lǐng)導(dǎo)、山東社保項目組、朋友、其他。

說真的我沒看出來這種管理方式的優(yōu)點(diǎn)。我覺得這種方式跟沒管理沒啥區(qū)別。真的。

4、狀態(tài)分類型：
按照郵件所關(guān)聯(lián)的工作的狀態(tài)進(jìn)行分類。可以分成：待辦、正在處理、已經(jīng)處理、已經(jīng)延遲和其他幾個部分。

有的項目經(jīng)理是采用這種方式來管理郵件的。所有的未讀郵件都是待分類的郵件。之后通過手工揀選的方式來進(jìn)行管理。

這種方式，不是很便于存檔和查詢（試想，過了一段時間之后，已經(jīng)處理這個文件夾里面會有多少郵件？）。

總結(jié)一下：
1、郵件會越積越多的。相信我，真的會越積越多的
2、郵件對工作非常重要，所以郵件的歸檔、保存和檢索都非常重要
3、從目前的效果上看，郵件客戶端仍然無法被GMail的Ajax客戶端代替
4、最好要根據(jù)自己的工作性質(zhì)，決定出一個適合自己的郵件管理風(fēng)格。在這個基礎(chǔ)上還可以應(yīng)用很多的技巧。機(jī)器不怕重復(fù)，但是人都害怕復(fù)雜

好了，下一篇里，我將把我所知的郵件管理的技巧都寫出來。也作為一個存檔。留待以后接著完善吧。

另外，關(guān)于電子郵件寫得太多，未免開始離題了。再寫一篇，就要開始寫電子書/文檔的管理（我打算把這個方面重點(diǎn)寫一寫）了。

posted @ 2008-08-24 10:26 guitarpoet 閱讀(605) | 評論 (0) | 編輯 收藏

關(guān)于電子郵件

關(guān)于電子郵件

好了，今天來討論電子郵件。

電子郵件是非常優(yōu)雅和浪漫的交流方式——郵件的電子表示方式。它擁有前輩的很多優(yōu)點(diǎn)，在某些方面上甚至超出了前輩。

但是，你雖然可以把信紙換成薰衣草的顏色，你卻無論如何也無法發(fā)出有薰衣草香氣的信來。有時候，歪歪扭扭的手寫字，要比你選擇的任何字體都能代表你的心意。——你休想拿電子郵件寫出完美的情書來。呵呵。

好了，言歸正傳，我們先列舉一下電子郵件的特性吧。

1、只讀：電子郵件的只讀特性與它的前輩一樣，你無法改掉別人發(fā)給你的郵件，你只能選擇保留還是扔掉它。因為這一點(diǎn)，電子郵件是有法律上的證據(jù)意義的。以我的了解，世界上某些國家——包括中國，都可以用電子郵件存根作為證據(jù)。
2、異步：異步的消息發(fā)送方式，使得非同時工作（時區(qū)差異、地區(qū)差異等）變得容易，而且使得個人工作的安排和調(diào)度方式更加靈活（你可以選擇何時去收郵件，收到郵件后何時進(jìn)行處理）。
3、高效：雖然，相對于前輩，電子郵件的發(fā)送和接收都容易了很多。但是，由于電子郵件仍然是郵件。在書寫電子郵件的時候，仍然需要經(jīng)過一定的構(gòu)思。務(wù)必達(dá)到條理清晰、言簡意賅的程度。雖然不能實現(xiàn)實時的溝通，在很多的情況下反倒會比實時的溝通有更高的溝通效果。
4、安全：基本上，所有的電子郵件服務(wù)器都采用了傳輸層加密了吧？如果再加入個人的公、私鑰加密的話。應(yīng)該說郵件信息的安全還是比較容易得到保證的。
5、檢索容易：當(dāng)然，這也和電子郵件的管理方式有關(guān)。不過，無論如何，電子郵件都比IM的聊天記錄容易檢索。比無法進(jìn)行記錄和檢索的語音聊天要高更多
6、溝通方便：靈活的使用電子郵件，可以非常方便的實現(xiàn)網(wǎng)絡(luò)異步會議室。實現(xiàn)非常好的溝通效果（比如Apache的Malling List或者Google Groups——不得不說，Google Groups是基于電子郵件的非常優(yōu)雅的應(yīng)用之一）。另外，通過靈活的使用CC。也可以非常大的提高溝通的效率。;)
7、使用方便：電子郵件已經(jīng)逐步的移動化，不管是iPhone還是藍(lán)莓，電子郵件都是非常重要的功能之一。在現(xiàn)在如果你愿意，你可以隨時訪問你的郵箱，發(fā)送、查看和管理郵件

好啦，就寫到這里吧。先在這里總結(jié)一下。下一篇再討論我的電子郵件管理方式。

1、良好的電子郵件溝通是高效工作的重要組成部分。Apache就是靠這個成功的，相信它吧。
2、電子郵件的異步和檢索容易的特性，對電子郵件的管理提出了很高的要求，在這一點(diǎn)上，有好的電子郵件管理方式要比沒有工作效率高很多
3、你終究會發(fā)現(xiàn)可以在任何時間、任何地點(diǎn)、任何機(jī)器上管理你的郵件是多么重要的一件事情。所以，放棄POP3，擁抱IMAP吧。

posted @ 2008-08-22 20:38 guitarpoet 閱讀(481) | 評論 (0) | 編輯 收藏

關(guān)于個人文檔管理－圖片和視頻文件

昨天又寫了一篇又臭又長的文章。從今天起，篇幅力圖達(dá)到短小精悍。

我不是一個攝影愛好者（所以到現(xiàn)在還沒有數(shù)碼相機(jī)），也不是一個很愛拍照的人。我自己拍得最多的就是每周一次用筆記本拍的減肥效果記錄。

由于電影一般看完就刪、很多音樂視頻都可以在網(wǎng)上看，而我又不愛看電視節(jié)目，所以我的視頻簡直屈指可數(shù)。

視頻和圖片的最大的特點(diǎn)就是它們都是大把吃掉硬盤的怪物。舉例來說，一個SRV的Live from Austin Texas就吃掉了我700M的硬盤。我的工作區(qū)中所有的文檔大小的總和都不及它的一半。

我對待視頻的策略，仍然是我用的最熟的大抽屜策略：最常看的和馬上要看的視頻（比如最新的電影），放到Movies文件夾中。其他需要保留的經(jīng)典，刻盤保存（太大了，裝它們移動硬盤吃不消）。

由于我再看它們的可能性不是非常的大，所以刻盤保存的風(fēng)險我可以接受。

我使用iPhoto來管理我的圖片。用iPhoto來管理相片的體驗，和用iTunes管理音樂差不多。只不過播放列表變成了相冊。我自定義了一個關(guān)鍵字“減肥日記“（開始是想每天照，可是我實在太懶，呵呵），我每周拍的減肥效果記錄都會加上這個關(guān)鍵字。在這個基礎(chǔ)上，我建立了一個查詢，列出所有關(guān)鍵字為”減肥日記“的相片。這樣，我的減肥效果就可以一目了然了。哈哈。

總結(jié)一下：

1、視頻由于體積大，收看次數(shù)較少。可以考慮采用刻盤歸檔的方式。但是一定要預(yù)留一些空間使用大抽屜原則（常用的東西放到最容易找到的地方）。在使用刻盤保存的時候，一定要考慮為所有的光盤建立可供檢索和查詢的索引（光盤的編號、光盤的內(nèi)容、光盤的存檔時間）。對于個人而言，這些只要一個Excel表格足矣，不需要什么額外的軟件。
2、圖片的管理方案與音樂異曲同工。因為除了媒介和使用方式有所不同外。二者的根本都是大的二進(jìn)制文件 ＋ 圍繞這個文件的一系列元數(shù)據(jù)。而且，與音樂一樣圖片數(shù)據(jù)的備份和查看也被iPod很好的支持。

關(guān)于我的圖片和視頻的管理方式，就到這里吧。下一篇需要討論的，是對工作非常重要的，電子郵件的管理。由于它太重要了，而且涉及到的技巧也太多了（很多人都有很優(yōu)秀的經(jīng)驗）。如果一篇寫不完，可以考慮多寫幾篇。:-)

posted @ 2008-08-19 09:32 guitarpoet 閱讀(1186) | 評論 (2) | 編輯 收藏

關(guān)于個人文檔管理 — 個人音樂管理

好了，接著昨天的話題，說一下我的音樂文件管理。

托生在中國的福，我只花了很少的代價，就聽到了很多高質(zhì)量的音樂（誰都知道是怎么回事，呵呵）。

對于我這種須臾離不開音樂的人來說。找到自己今天、現(xiàn)在想聽的音樂。并不是一件非常容易的事情。

說起個人的音樂管理，我打算從革命的傳家史開始。

我的音樂管理可以分為下面幾個階段。

1、卡帶 ＋ 錄音機(jī)：
    所有的卡帶都放到寫字臺的大抽屜里。大抽屜放不下后，則把所有的音樂分成兩批：常聽的、不常聽的。不常聽的放到寫字臺的柜子里。常聽的放到大抽屜里（對，就像當(dāng)時賣卡帶的店一樣，不過是按照個人好惡來排序的，最愛聽的，放到最外面）。
   
    當(dāng)我要開始聽音樂的時候（也就是寫作業(yè)或者看書的時候），我會拿出五盤卡帶（要知道5 × 45，時間也不短了，呵呵）。作為最終手頭的音樂。

2、卡帶 ＋ 隨身聽：
    我有了第一個隨身聽的時候，終于可以實現(xiàn)邊走路邊聽歌的欲望了。從那個時候起，我的書包里開始放卡帶。不過，雖然設(shè)備升級了，我還是用以前的管理方式。

3、CD ＋ CD隨身聽
    我在有CD隨身聽之前就開始聽CD了（托VCD流行的福）。開始我的CD不多，沒過多久就有PC了（大學(xué)的時候）。所以，這個階段乏善可陳。

4、PC ＋ 播放器 ＋ MP3（硬件設(shè)備，呵呵）
    有了CD、PC和MP3之后，卡帶對我就已經(jīng)成了歷史，我成功的以不算太低的價格（2元一盤？）把我所有的卡帶都甩了出去，除了幾個實在舍不得的（比如魯?shù)婪虻呢惗喾忆撉僮帏Q曲、布魯諾的馬勒第九）。當(dāng)時用的播放器是Windows Media Player、金山影霸（多難聽的名字？）。文件管理也很簡單，每個CD一個文件夾。而且，沒有任何的元數(shù)據(jù)，全是Track1.wma、Track9.wma，呵呵。

    我的第一個MP3小得可憐，128M。放我從CD抓的WMA文件，只能放一張專輯多（放交響曲的話，最多也就是兩個）。只能每天都在曲庫（一個文件夾——跟我管理的卡帶的大抽屜異曲同工）里挑——真的是精挑細(xì)選。

    之后是刪除、拷貝操作。然后是打開MP3的循環(huán)播放。

    在PC上，我有幾個常用的播放列表。這樣在使用WMP的時候，就可以很容易找到自己想聽的歌了。

    這種方式非常差勁，我經(jīng)常會丟掉我的元數(shù)據(jù)、播放列表，尤其是在重裝系統(tǒng)的時候。

5、PC ＋ iTunes ＋ iPod——現(xiàn)在
    經(jīng)過多年，我還是入了Apple的賊船，進(jìn)入了iPod的圈套。好了，我來仔細(xì)的講一下我現(xiàn)在的音樂管理吧。

我現(xiàn)在的音樂管理方式：

1、所有音樂集中管理：
    我盡可能的把我所有的音樂都集中的管理起來（目前是幾百張專輯吧——不多），十幾個G的音樂統(tǒng)一的交給iTunes來管理。我之后買的所有的CD，全都是在用iTunes抓軌之后收藏。只聽iTunes管理的音樂。

2、收集和整理音樂的元數(shù)據(jù)：
    對于音樂，iTunes可以支持的元數(shù)據(jù)有：名稱、表演者、年份、歌詞、專輯表演者、軌道編號、BPM、專輯名、專輯圖、光盤編號、風(fēng)格、作曲、歸類、注釋、評價、音量、均衡器、播放次數(shù)。
   
    其中后面的歸類、注釋、評價、音量、均衡器、播放次數(shù)這些元數(shù)據(jù)是可以自行定義的，而前面的元數(shù)據(jù)則是可以通過各種方式來獲取到的。

    我在抓取CD的時候，一定會保證iTunes能夠正常的連接到互聯(lián)網(wǎng)。讓它通過互聯(lián)網(wǎng)替我找到唱片的元數(shù)據(jù)。并把這些元數(shù)據(jù)保存在抓取的文件以及曲庫中。我也盡我最大的能力把其余欠缺的元數(shù)據(jù)補(bǔ)充上（從網(wǎng)上下載的音樂，一般說來，元數(shù)據(jù)都損失得很大——有的下載站確實太過分了，把所有的元數(shù)據(jù)都刷成它們的網(wǎng)址）。

3、建立播放列表
    要想時刻找到想聽的音樂，播放列表是必不可少的（尤其對iPod而言）。我機(jī)器上建立的播放列表，基本上都是以精選為主（比如On my way、On my way II等），因為我在坐車、船、走路的時候，更多的是聽podcast或者是聽隨機(jī)播放。只有在某些嘈雜的場合（比如飛機(jī)上或者聽podcast聽累了）或者是不便于操作iPod的時候（比如騎自行車的時候）才會改聽精選。我的精選是我精心的挑的高頻段比較明顯，并且旋律一般都處于高頻段的音樂，這樣可以盡量的避免周圍環(huán)境噪音對音樂的干擾，卻可以讓我能夠盡可能的聽清周圍的聲音。

4、建立并保存查詢
    iTunes的查詢能力做得很不錯，而且你可以把查詢作為動態(tài)的播放列表保存。這個概念很讓人受用（尤其在音樂的元數(shù)據(jù)得到良好的維護(hù)之后）。我的智能播放列表不多，列舉幾個吧：Ragtime（我的所有風(fēng)格是Ragtime的音樂列表）、JS Bach By Gould（我的所有由Gould演奏的作曲家為JS Bach的音樂列表）、My Favorite not played since last week（所有我的評價在四星以上并且至少有一周沒有播放過的音樂列表）

5、隨機(jī)播放
    對于我來說，我有數(shù)千個音樂文件（肯定會有人比我更多，比如我的一個朋友，光CD就數(shù)千），天天從中挑想聽的音樂，是一件很乏味的事情，而且會造成過度的挑食。更有趣的是，有時候我都會忘記我有某個專輯。而有的專輯我抓進(jìn)我的曲庫之后，一次都沒有聽過。而且，不同的時候、不同的情緒，聽不同的音樂也有不同的感覺。

    所以我的策略是一般的情況下，我都是用隨機(jī)播放。如果這首歌不喜歡，就給個差評，跳到下一首。讓iTunes來幫我記錄播放次數(shù)。這個元數(shù)據(jù)對我管理音樂和評價音樂也有很高的應(yīng)用價值。而iPod能夠很好的支持這個元數(shù)據(jù)。僅為這一點(diǎn)，我就離不開iTunes和iPod了。

6、下載和管理podcast
    聽/看Podcast真是一件讓人上癮的事情。iTunes把Podcast區(qū)別對待的方式，是我最舒服的方式（因為我就是用了iTunes后開始聽Podcast的，第一印象永遠(yuǎn)是最有力的）。

    我訂閱了二十幾個podcast，到現(xiàn)在只有二百多個文件，而且，podcast的最大特點(diǎn)就是時效性特別強(qiáng)，一般是聽完、看完一遍就刪掉了，所以不存在管理的問題。

7、其他格式的音樂
    iTunes支持播放的音樂格式很少。為了統(tǒng)一的管理所有的音樂，我把所有的其他格式的音樂都轉(zhuǎn)成了MP3。

8、iPod移動方案
    我的由iTunes管理的音樂（Podcast ＋ 音樂 ＋ iPod能播放的視頻）總共不到20G。裝在我的30G的iPod中綽綽有余。我每次出門都會帶著我所有的音樂。我在使用iPod之前絕對會認(rèn)為這是不可思議的。

9、備份管理
    我的所有音樂都在我的MacBook里。MacBook是源。我的30G iPod與MacBook完全同步，是第一手備份。我還有一個120G的專有備份移動硬盤（用來備份我的Home文件夾，當(dāng)然，同時也就備份了音樂、和iTunes元數(shù)據(jù)——以后會說）是第二手備份。我覺得我有足夠的信心相信這三個設(shè)備不會同時壞掉，只要有一個備份，我就能恢復(fù)我所有的音樂。我不刻盤，盤刻多了不好管理。而且，光盤更不好保存，不如硬盤——起碼我覺得，當(dāng)然了，我買不起磁帶機(jī)。

回顧到現(xiàn)在，我覺得這么多年來，我仿佛在音樂管理方面沒有任何進(jìn)步，進(jìn)步的只是技術(shù)。呵呵。

總結(jié)一下：

1、我認(rèn)為，個人的音樂應(yīng)該統(tǒng)一的交給一個軟件來統(tǒng)一的進(jìn)行管理 —— 原因，使用和備份都方便。能夠?qū)崿F(xiàn)一套元數(shù)據(jù)是最好的
2、音樂應(yīng)該是隨機(jī)的聽的
3、音樂的元數(shù)據(jù)非常重要，尤其是在你對音樂要求很高或者你的音樂非常多的時候
4、要善用音樂管理軟件的自定義查詢功能，能夠發(fā)揮個人的創(chuàng)意就更好了

當(dāng)然，現(xiàn)在網(wǎng)絡(luò)的音樂電臺也是聽音樂的一個非常不錯的選擇。不過極其可惜的是Pandora并不面向大陸開放。而感覺大陸的網(wǎng)絡(luò)音樂電臺中我想聽的音樂并不是很多。

我很看好網(wǎng)絡(luò)音樂電臺。試想，如果能夠?qū)崿F(xiàn)網(wǎng)絡(luò) ＋ PC ＋ 手機(jī)的無縫結(jié)合。保證可以隨時聽到想聽的高質(zhì)量的音樂，并且系統(tǒng)可以統(tǒng)一的管理所有你相關(guān)的音樂的元數(shù)據(jù)。又可以免去管理、維護(hù)音樂文件的煩惱。是多么愜意的事情？

我愿意為這個服務(wù)付費(fèi)，因為我每天都要聽音樂，所以即使是每天10元（也就是每年4K的服務(wù)費(fèi)，我也可以接受——因為我還省去了購買專輯和維護(hù)CD的支出）。

posted @ 2008-08-18 12:49 guitarpoet 閱讀(716) | 評論 (0) | 編輯 收藏

關(guān)于個人文檔管理

 這幾天開始整理個人文檔。整理的過程中，感覺到有必要把我在個人文檔管理中的一些經(jīng)驗總結(jié)一下。

誠然，一個人的文檔管理風(fēng)格，跟一個人的性格和能力有很大的關(guān)系，跟他的臥室（如果是結(jié)婚了的話，那就看辦公室吧）也有很大的關(guān)系。:-)

其實，優(yōu)秀的個人文檔管理的精髓就是能夠在需要的時候找到需要的東西（當(dāng)然，是自己的東西）。不管你用何種方式，不管你采用何種手段。

首先，我打算區(qū)分一下個人電子文檔的類別。

所有的個人電子文檔都可以就需不需要進(jìn)行變更管理分成兩類：需要進(jìn)行變更管理的和不需要進(jìn)行變更管理的。

不需要進(jìn)行變更管理的最典型例子就是郵件。一旦閱讀完畢，它就變成了歷史，只有查閱和轉(zhuǎn)發(fā)的功能了。各種電子書、電子文檔、媒體文件（音樂、視頻、圖片等）等，它們和電子郵件的情形基本一樣，對一般人來說也都是不需要進(jìn)行變更管理的。

需要進(jìn)行變更管理的文檔，我把它們一律稱之為工作文檔。關(guān)于工作文檔的管理，我打算在討論完不需要進(jìn)行變更管理的文檔以后再討論。

那么，不需要進(jìn)行變更管理的文檔。怎樣進(jìn)行管理比較好呢？

我先說說我自己的經(jīng)驗吧。

我把我的不需要進(jìn)行變更管理的文檔分成5種類型：音樂、視頻、圖片、Email和電子書。

我打算在下一篇的blog里，寫寫我的音樂文件的管理方式。

posted @ 2008-08-17 09:10 guitarpoet 閱讀(1573) | 評論 (2) | 編輯 收藏

關(guān)于基于JavaSript的RIA客戶端數(shù)據(jù)處理（下）

一、引子

上一篇討論了關(guān)于客戶端數(shù)據(jù)處理的一些問題，以簡單的用例場景的方式描述了出來。很明顯，要想實現(xiàn)一個功能完整的Rich客戶端的話，必須能夠滿足上述用例場景的需求。能否根據(jù)這些需求做出合理的設(shè)計，是一個挑戰(zhàn)。尤其對于設(shè)計而言，不同的人有著不同的風(fēng)格，而且由于背景不同，也會有不同的見解。本文中，我只是陳述出自己的一些想法和設(shè)想，更多的是希望能夠拋磚引玉，通過在這個方面的討論也能增進(jìn)我的理解。呵呵。

很顯然，blog的形式更適合作為思路的介紹以及探討的平臺，而不是詳細(xì)設(shè)計的文檔。而且很明顯這一篇文章是承載不了所有的詳細(xì)設(shè)計的。我爭取把我在各個細(xì)化的方面的想法在后續(xù)的文章里面發(fā)出來。如果時間允許的話，整理出初始的文檔和代碼，建立一個小的開源項目未嘗不可（因為如此，所有的JS都是采用英文來注釋──其實還有一個原因是練習(xí)英文 :)）。這都是后話了。

二、縮略語

1. RIA：Rich Internet Application的縮寫。RIA是擁有傳統(tǒng)本地應(yīng)用的功能和效果的Web應(yīng)用。RIA一般把UI相關(guān)的處理交給了Web客戶端，但是大量的數(shù)據(jù)（包括應(yīng)用的狀態(tài)、數(shù)據(jù)等）還是交給服務(wù)端處理

2. Ajax：又寫為AJAX，是"Asynchronous JavaScript and XML"的縮寫。是一種使用瀏覽器技術(shù)進(jìn)行RIA開發(fā)的技術(shù)

3. Prototype：開源的優(yōu)雅的Ajax以及JavaScript基礎(chǔ)擴(kuò)展框架。由于被Rails采用而聞名，使用相當(dāng)廣泛
4. jQuery：功能類似Prototype + script.aculo.us的開源Ajax框架。據(jù)我所知，Google用得比較多
   
5. Ext：對YUI的一個擴(kuò)展的UI構(gòu)件庫。經(jīng)過改進(jìn)后，可以使用jQuery或者Prototype作為基礎(chǔ)。目前好像正在完善自身的基礎(chǔ)Ext base。以優(yōu)秀的構(gòu)件聞名。雖然目前仍然屬于商業(yè)構(gòu)件庫，但是License相對寬松，一般的商業(yè)應(yīng)用可以免費(fèi)使用
   

6. dojo：由dojo foundation管理的一個開源JavaScript框架。提供了很好的JavaScript擴(kuò)展，目前被IBM和Sun等大公司支持和使用

7. Json： JavaScript Object Notation的縮寫。它是一種純文本的數(shù)據(jù)對象傳輸協(xié)議，在Ajax的應(yīng)用中被廣泛采用

8. CRUD：Create（創(chuàng)建）、Retrieve（獲取）、Update（更新）和Delete（刪除）這四種簡單的數(shù)據(jù)操作的縮寫

9. Form：本文中的Form指的是經(jīng)過Ajax擴(kuò)展的簡單的HTML電子表單。表單內(nèi)部可以擁有很多如ComboBox、TextBox等構(gòu)件。一般來說，一個表單對應(yīng)著一個業(yè)務(wù)的數(shù)據(jù)對象

10. Tree：樹形顯示結(jié)構(gòu)化數(shù)據(jù)的構(gòu)件，由于數(shù)據(jù)是高度結(jié)構(gòu)化的，往往可以采用懶加載等技術(shù)來提高性能

11. Grid：以表格形式顯示和編輯數(shù)據(jù)的UI構(gòu)件。一般分為表頭（標(biāo)題欄）、表身（數(shù)據(jù)列表）和表尾（合計、狀態(tài)顯示等）三個部分。其中，表頭可以是復(fù)合的表頭，而表身可以是復(fù)合的格式（Tree、Grid、ComboBox、CheckBox等）。一個Grid可以有一個復(fù)雜的Grid定義

12. Enhanced Grid：下面簡稱為EGrid，是Grid的擴(kuò)展。在Grid的功能基礎(chǔ)之上提供了數(shù)據(jù)獲取和數(shù)據(jù)持久化的能力，可以大大的減少開發(fā)應(yīng)用的時間（Ext中的Grid可以認(rèn)為是一個簡化了的EGrid）

13. CodeList：代碼表，一般用在下拉列表數(shù)據(jù)處，在系統(tǒng)的實現(xiàn)中，由于性能以及標(biāo)準(zhǔn)的要求，下拉列表一般都是采用代碼保存數(shù)據(jù)，但是用戶在填寫表單的時候需要看到正常的文字而不是代碼，這就需要系統(tǒng)通過CodeList進(jìn)行文字和代碼的轉(zhuǎn)換

14. LRU：Least Recent Used的縮寫，是一種簡單的緩存策略，如果緩存已滿，那么就釋放最近最少使用的那個緩存數(shù)據(jù)

15. REST：是REpresentational State Transfer的縮寫，是一種基于輕量級WebService協(xié)議

16. JDBC：是Java DataBase Connectivity對縮寫，是基于Java的數(shù)據(jù)庫連接規(guī)范。

三、基礎(chǔ)

既然決定采用Ajax，就最好采用一個基礎(chǔ)，在這個有很多優(yōu)秀的Ajax框架可供選擇的時代，誰要是還要赤手空拳的來寫Ajax應(yīng)用，就未免有點(diǎn)兒過于勇敢，而近于魯莽了。這篇文章不是Ajax框架對比文章，我不打算在這里一一列舉各個流行的Ajax框架的優(yōu)缺點(diǎn)，我只拿下面幾個進(jìn)行討論，dojo、Prototype、jQuery、Ext。

先提需求，框架應(yīng)該：

1. 以一種形式支持面向?qū)ο螅ó吘归_發(fā)人員多數(shù)都是Java程序員，更有可能的是，他/她只對Java熟悉）
2. 以一種方式來支持命名空間和分包機(jī)制（開發(fā)企業(yè)應(yīng)用與開發(fā)網(wǎng)站不同，復(fù)雜的不是技術(shù)而是業(yè)務(wù)。沒有命名空間和分包支持，對于大型應(yīng)用，基本不可控制。──設(shè)想一下如果Java沒有package關(guān)鍵字會怎樣）
3. 有完善的模塊封裝與管理規(guī)范或者最佳實踐，能夠自動處理模塊間的依賴則更好（模塊的定義不在這里解釋了，一個例子說明吧，一個Jar就是一個模塊。模塊化和構(gòu)件化是實現(xiàn)、維護(hù)和管理大型應(yīng)用的重要手段）
4. 提供豐富的調(diào)優(yōu)選項，使得對復(fù)雜的應(yīng)用調(diào)優(yōu)是可能的（這一點(diǎn)對于UI層尤為重要，因為它直接面對使用者）
5. 便于調(diào)試（這一點(diǎn)對于開發(fā)者致關(guān)重要）

綜合上面幾點(diǎn)，我選擇dojo作為基礎(chǔ)。Sorry Prototype。

四、整體構(gòu)架

整體構(gòu)架如下圖所示（為了便于理解UI構(gòu)件與其對關(guān)系，我把需要數(shù)據(jù)處理的UI構(gòu)件也加了上去，圖中藍(lán)背景色的部分就是）：
一目了然，整個客戶端數(shù)據(jù)處理由3個部分構(gòu)成，DataSource、DataSet和DataStore。下面分別進(jìn)行簡單的介紹。

五、DataSet

DataSet的概念很簡單，就是數(shù)據(jù)對象的集合。它的構(gòu)架如下圖所示（注意：DataSet只是一套標(biāo)準(zhǔn)的API，可以有不同的實現(xiàn)——比如XML形式的）：

如圖所示，DataSet由四個部分構(gòu)成，Record Set（數(shù)據(jù)集合）、Change Tracker（數(shù)據(jù)變更追蹤）、Meta Data（數(shù)據(jù)對象源信息）和Cursors（游標(biāo)API）。

分別介紹如下：

1. Record Set：Record Set就是Record的集合，一個Record就是一個數(shù)據(jù)對象，它由一系列的屬性（Property）構(gòu)成，屬性是一個簡單的字符串，其對應(yīng)的值可以是任意類型。Record提供屬性讀寫的方法，可以直接在Record上對屬性進(jìn)行讀寫，并且，Record會為寫操作提供一個事件。Record Set內(nèi)部的元素必須是Record，Record Set支持對內(nèi)部Record的CRUD操作。并且會有相應(yīng)的事件觸發(fā)
2. Change Tracker：ChangeTracker為DataSet提供所有寫操作的追蹤，可以通過配置選擇Change Tracker是否記錄修改，如果記錄修改，采用的是針對每一個Record記錄增加、刪除以及針對每一個屬性記錄First和Last修改的策略
3. Meta Data：提供DataSet中Record的元數(shù)據(jù)（屬性名、屬性對應(yīng)類型、其他自定義數(shù)據(jù)——校驗、Form Label信息、表頭信息等）以及DataSet的元數(shù)據(jù)（在全部數(shù)據(jù)中的位置等）。
4. Cursors：Cursor其實就是Record的迭代器，可以通過對dataset查詢（一般都是非常簡單的filter或者range）得到，推薦通過Cursor進(jìn)行Record訪問，而不是通過Index，因為通過迭代器訪問Record，DataSet擁有更多的能力。雖然通過Cursor完全可以訪問所有的Record及其中的數(shù)據(jù)，但是由于DataSet擁有MetaData，所以還是采用DataSet作為數(shù)據(jù)綁定的主體

DataSet是整個客戶端數(shù)據(jù)處理構(gòu)架的核心，所有的數(shù)據(jù)訪問都應(yīng)該通過DataSet的API。這樣客戶端的數(shù)據(jù)處理才是統(tǒng)一的一個整體。

解決的用例問題：

• 數(shù)據(jù)綁定：Form綁定、Grid綁定
• 數(shù)據(jù)變更追蹤：Grid變更提示、數(shù)據(jù)集合變更追蹤、Form修改的追蹤
• 數(shù)據(jù)訪問：數(shù)據(jù)對象元數(shù)據(jù)信息訪問、數(shù)據(jù)寫操作的統(tǒng)一事件定義、統(tǒng)一的數(shù)據(jù)讀取方式

六、DataSource

DataSource的功能是提供對數(shù)據(jù)進(jìn)行查詢以及數(shù)據(jù)的持久化（持久化到客戶端或者服務(wù)器端）。與DataSet一樣，不同的格式數(shù)據(jù)就會有不同的DataSource，一種DataSource代表了一種客戶端與服務(wù)端的數(shù)據(jù)傳輸協(xié)議。但是由于DataSource的邏輯與結(jié)構(gòu)過于復(fù)雜（事實上，DataSet的實現(xiàn)也完全依賴DataSource的實現(xiàn)，可以類比JDBC），不應(yīng)該對每一種格式都重新實現(xiàn)一個DataSource，由此，DataSource不應(yīng)該是一套標(biāo)準(zhǔn)的API，而是使用了Adapter模式，來滿足不同的數(shù)據(jù)來源，其構(gòu)架如下圖所示：
看上去很簡單？實際上這是最復(fù)雜的部分，關(guān)于這個部分，至少可以再寫3篇文章來詳細(xì)探討，在本文中，就不過度討論了。:)

如圖所示，DataSource由Cache、Query、Persist以及Providers構(gòu)成，分別介紹如下：

1. Cache：Cache的概念在前面已經(jīng)闡述了，不在這里多說了。在這里簡單的介紹一下客戶端Cache的策略以及技術(shù)，由于基于瀏覽器的數(shù)據(jù)緩存技術(shù)非常重要，擬在后續(xù)的文檔《客戶端的緩存策略與相關(guān)技術(shù)》中對其進(jìn)行詳細(xì)討論
• 緩存策略（這一方面客戶端數(shù)據(jù)的緩存與服務(wù)端的數(shù)據(jù)緩存考慮的問題應(yīng)該是類似的，唯一的區(qū)別是，客戶端的數(shù)據(jù)緩存不必考慮集群支持。:)）
• LRU：基礎(chǔ)的Cache算法，如果緩存已滿時，根據(jù)最近很少使用算法來確定哪些對象需要被清除
• Priority：按照優(yōu)先級高低來清理緩存空間的策略，當(dāng)緩存已滿時，按照優(yōu)先級高低來確定哪些對象需要被清除，可以與LRU算法共存
• Refreshable：有時效性的數(shù)據(jù)，或者在運(yùn)行時有可能會被修改需要同步或者刷新的數(shù)據(jù)。可以設(shè)置數(shù)據(jù)過期時間，到時間則數(shù)據(jù)處于stale狀態(tài)，再度訪問該數(shù)據(jù)時，如果不能重新獲得該數(shù)據(jù)，則報錯
• Expireable：臨時性數(shù)據(jù)，可以設(shè)置失效時間，到時間則數(shù)據(jù)失效，在緩存需要清理時，緩存會清理掉這些失效的對象
• 緩存持久化（屬于高級的緩存策略，依賴客戶端基于JavaScript的數(shù)據(jù)存儲技術(shù)）
• Save（持久化）：把緩存當(dāng)中的數(shù)據(jù)持久化到本地或者服務(wù)端，其用處如下
• 通過把數(shù)據(jù)持久化可以增加Cache的容量
• 數(shù)據(jù)本地緩存提供了離線表單填寫的能力
• Retrieve、Delete：對緩存中數(shù)據(jù)的基本操作
• Sync：離線緩存的本地數(shù)據(jù)，可以與遠(yuǎn)程服務(wù)端進(jìn)行同步，從而實現(xiàn)離線表單提交以及實現(xiàn)離線CodeList等功能
• 緩存技術(shù)
• Client
• 內(nèi)存引用
• Cookie
  
• Google Gear
• Server（服務(wù)端協(xié)助客戶端做一些緩存，這在傳統(tǒng)的B/S下是匪夷所思的設(shè)計，在RIA的情況下卻未嘗不是一種手段）
• WebService或者REST
• Post + Get
2. Query：其實Query只是一個方法，由于有可能會向服務(wù)端發(fā)XmlHttpRequest，所以這個方法需要回調(diào)方法。其參數(shù)應(yīng)該是一個Query對象，一個配置對象，有一些事件的關(guān)鍵字（onBegin、onError、onSuccess等）。Query對象以及配置對象的格式在本文中就不詳細(xì)說明了，留給以后慢慢說（因為這個部分是我最喜歡的部分）。很明顯，如果查詢成功，查詢的結(jié)果應(yīng)該是DataSet，一般來說，DataSource是DataSet來源。不同的DataSource，查詢的語言未必相同。不一定所有的查詢對象都支持SQL語法（比如可以支持HQL或者XQuery啊），而且我最推薦采用的是服務(wù)端提供一個服務(wù)抽象層，接受Json格式的查詢請求，并返回Json格式的數(shù)據(jù)
3. Persist：數(shù)據(jù)持久化。只是Save和Update兩個方法。接受DataSet和配置對象作為參數(shù)（這兩個方法也應(yīng)該是異步的）。如果DataSet里面沒有足夠的元數(shù)據(jù)信息，需要在配置對象里面提供這些信息。這個部分不比Query部分復(fù)雜
4. Providers：數(shù)據(jù)的來源，提供了Query和Persist API的實現(xiàn)，是DataSource的底層實現(xiàn)，它使DataSource的實現(xiàn)可以跨不同協(xié)議而使用。給DataSource提供不同的Provider，DataSource就可以支持不同的數(shù)據(jù)傳輸協(xié)議。

DataSource是數(shù)據(jù)查詢和持久化的核心，所有的客戶端的數(shù)據(jù)查詢和持久化基本都應(yīng)該采用DataSource，從而獲得DataSource提供的強(qiáng)大而靈活的特性。

解決的用例問題：

• 數(shù)據(jù)緩存：離線運(yùn)行的CodeList、離線表單填寫、性能考慮
• 數(shù)據(jù)查詢：樣本查詢、模糊查詢、Range查詢、邏輯查詢、自定義查詢
• 數(shù)據(jù)處理：數(shù)據(jù)處理事件、過濾、排序

七、DataStore

DataStore基于DataSource和DataSet的實現(xiàn)，實現(xiàn)了dojo的data api。這樣既實現(xiàn)了對需要dojo api的dojo構(gòu)件的支持，又滿足了類似Tree、EGrid這種既需要綁定又需要數(shù)據(jù)來源的高級構(gòu)件的要求。總體來說，DataStore只是薄薄的一層接口，實際的實現(xiàn)完全依賴于DataSource。

解決的用例問題：

• 數(shù)據(jù)綁定、查詢、處理：Tree綁定、ComboBox數(shù)據(jù)源、EGrid綁定

八、待討論的問題

客戶端的數(shù)據(jù)處理事實上要比我想象得還要復(fù)雜，我還有一些設(shè)計決策沒有確定，列舉下來以供討論吧。

8.1 客戶端的事務(wù)處理？

由于很多數(shù)據(jù)處理都放在了客戶端。客戶端的數(shù)據(jù)處理操作相應(yīng)增多而且復(fù)雜，是否應(yīng)該在DataSource中添加寫事務(wù)的處理？以便對數(shù)據(jù)操作進(jìn)行更細(xì)粒度的管理，而不是僅僅停留在Query、Save和Track階段？

8.2 權(quán)限數(shù)據(jù)的來源

如果可以連接到服務(wù)端，用戶在向服務(wù)端登錄后，服務(wù)端會返回用戶的權(quán)限信息列表。客戶端接收后，可以相應(yīng)的提供權(quán)限控制。但是，如果客戶端離線運(yùn)行，用戶無法向服務(wù)的登錄，權(quán)限信息列表無從獲得，怎么提供權(quán)限控制？

探討方案1：離線客戶端無須登錄，由于沒有權(quán)限控制列表，默認(rèn)擁有系統(tǒng)最低權(quán)限（固定的配置在客戶端），由系統(tǒng)開發(fā)人員決定用戶在離線時可以進(jìn)行何種操作。用戶在線提交數(shù)據(jù)的時候，服務(wù)端也要根據(jù)相應(yīng)的權(quán)限進(jìn)行驗證以防止越權(quán)的數(shù)據(jù)操作

探討方案2：離線客戶端仍須登錄，權(quán)限控制列表使用用戶在線登錄時緩存的數(shù)據(jù)。其余與在線方式相同。如果用戶沒有在線登錄過，那么離線應(yīng)用無法使用。

8.3 跨域數(shù)據(jù)的來源

由于瀏覽器的安全性策略，JavaScript無法向除本身域之外的其他服務(wù)器發(fā)送請求。也就是說，對于JavaScript而言，所有的數(shù)據(jù)必須來源于同一個域的服務(wù)器。對客戶端進(jìn)行集成非常不利。

探討方案1：服務(wù)端提供一個服務(wù)接入層，接受如Spring Bean、EJB、JMS、WebService等形式的服務(wù)，并且把所有的服務(wù)都轉(zhuǎn)化成為一種固定格式的協(xié)議與客戶端交互。所有的服務(wù)集成與協(xié)議轉(zhuǎn)化都交給服務(wù)端，對客戶端完全透明。

探討方案2：服務(wù)端提供一個簡單的Proxy，通過一定的協(xié)議把請求和回復(fù)轉(zhuǎn)發(fā)給客戶端，處理交給客戶端來做

九、小結(jié)

雖然到了這里，但是對于基于JavaScript的RIA客戶端數(shù)據(jù)處理的討論卻才剛剛開始，還需要很多后續(xù)的展開討論。但是，上午已經(jīng)過去了，需要去吃午飯了。:)

posted @ 2007-12-15 13:15 guitarpoet 閱讀(1450) | 評論 (2) | 編輯 收藏