Image Credit

之前一直在研究 Chrome Extension，而其中頻繁地使用了 HTML 的 Client-Side Storage Mechanism，所以就花了一些時間去 survey 了一下資料並整理如下：

一開始我想要先了解一下為什麼有了 Cookie 的存在，卻又還要在 HTML specification 中提出新的機制來儲存資料？而根據 Wiki 的資料 顯示，Cookie 雖然只是一個純文字的文件檔，但其實在 Browser 與 Server 做溝通時，都會被附加在 HTTP Header 的 Cookie 欄位，這就是為什麼 Cookie 的資料在前後端都可以被存儲的原因。

就在我了解了其存在的意義後，我就想要了解為什麼都已經存在著 Cookie 這樣的存取機制，卻還要在 HTML5 的 Specification 中提出新的存取機制？這是一個好問題，在看了 Stack Overflow 的討論文之後得到了答案。

有的時候，我們並不需要與 Server 做太多的互動，只是需要一個前端可以互相使用的存取機制就好，哪怕只是傳遞一些簡單的識別代號。因為有了這樣子的需求，那 Cookie 在某種程度上來說就太大材小用了，甚至可以說是過於痴肥。所以在做了這樣的理解之後，就可以合理的推測前端「輕量級的存取機制」之必要性。（時間點就沒有考究了）

那在 HTML5 的 Specification 中到底提到了什麼樣子的新型存取機制？原本可以歸類為下面三類：

1. Session Storage
2. Local Storage
3. Database Storage

之所以會說「原本」是因為 Database Storage 不知道因為什麼緣故就停止維護了（參閱下圖），所以我們就在此不做深入討論，只討論 Session 和 Local Storage。

如果要快速地了解兩者的差異，就是自己動手玩看看。

接下來還是要說明一下：Session 的中文是叫「會期」，就是一段會議、對話的期間，而在 HTML5 下，如果我們採用 Session Storage ，則我們資料的生命週期（Persistence）及生存範圍（Scope）都只能在一個 tab / window 下。說實在的，一時真的想不到該機制能應用在什麼樣的情況下，但 W3C 有提到一個有趣的情況，就是當一個使用者在進行拍賣的交易的時，雙開了兩個同樣帳號的 tab 來做購買的動作（接下來是我個人的情境補完），如果我們是利用 cookie 來紀錄欲購買商品的編號，那其實就很有可能因為兩個 tab 存取相同的 cookie 檔（沒有 lock）而造成交易上的異常。所以在這種時候 Session Storage 就相當適用。

而另外一個 Local Storage 和 Session Storage 的差異就在於 Persistence 和 Scope ，它是一個可以長時間儲存的機制，即使是在關閉 tab / window 之後，先前所儲存的資料依然保留著，而範圍就是所有的 tab / window 都能夠存取使用，除此之外，還能夠允許同個 domain 間的資料互相存取，因此在資料的傳遞上面佔有很大的優勢。以我自己為例，我在 Google Chrome Extension 的開發時，就大量應用到 Local Storage 來幫助我的外掛記錄使用者的偏好設定，以便於在各個子腳本中做資訊的傳遞。

以上就是這次 Client-Side Storage Mechanism 的研究，歡迎留言指教 :]

自從Google PageRank的論文出現之後，Google於搜尋引擎的市場就一直處於龍頭的地位，但是卻可以發現近期Google在Search Engine上的改良並沒有說特別的另人印象深刻，除了之前「社交資訊搜尋」及「改良介面後的圖片搜尋」這兩個服務還蠻有新意之外，似乎就只剩下頗具玩具性質的Google Instant而已。

特色沒什麼增加之外，不便性反而增加許多。而最近最讓我無法接受的就是Google Search的防洪機制，只要你多搜尋幾次同樣的關鍵字，就直接被導向到sorry.google.com…不知道是不是學網的問題，我很常遇到這個狀況，所以還要透過Yahoo的Search Engine才能找我想找的東西，真的是很不方便。

在傳統IR的時代之後，我們實驗室雖然是在做Search Engine，但是就立志要走和主流不同的方向，採用藍海策略以試圖在這片大海中找尋一盞明燈。「有用的創新」是我跟著老師這半年所學到的最重要的事情，也是實驗室研究的方向，如果我們想的是一個沒有用的點子，那我們不做，又如果我們做的是有用但是沒有創新的點子，我們還是不會讓步。我們只做有用又有創新的點子。

實驗室這一屆的專題生，也就是我和同學godChess，我們試著設計出專注於Plurk社交平台的Vertical Search Engine，所有的資料都是靠Spider從Plurk上抓下來的，完完全全只利用你在Plurk上提供的所有資訊（如個人資料或是噗的內容）而不依靠其他資訊，是一個完全信任於這個社交平台的搜尋引擎。

Image from Here

而有別於傳統搜尋引擎，我們提供給使用者搜尋的是「關係」而不是「關鍵字」，舉個例來說，你也許是一個很喜歡音樂的人，而你也想認識一些和你有同樣興趣的噗友，所以你就可以試著在Search Bar那邊輸入「音樂」這樣的關係，之後就會把分析過後，並符合該關係的噗友資訊提供給你，進一步把人與人之間的距離拉近，甚至是打破了虛擬與現實世界的界線。

而目前整個計畫已經進行到40%左右了，大約能夠在十二月完工，到時候再釋出網站連結來請有帳號的噗友來做個壓力測試吧，希望你們會喜歡:)。

共有16筆資料

說明:

圖上的每個間距是0.5(看統計者要統計到多詳細)，而中間那條線代表平均值(在本例為3.343)而藍色部分代表的是大於平均值的資料，紅色部分代表的是小於平均值的資料，然後依照離均差的大小來決定資料點是落在哪個圓內，之後依照圓內點的數目比上所有點的數目求出分佈機率(ex:最小圓有10個點，全部有16個點，其分佈機率為62.5%)

如果我們以平面的角度來看的話，會發現他的分佈情況是呈現在一個呈現兩色的二維鏢靶上，可以很明顯的看出整體資料的離均情況。在這邊要特別討論一下這個圖的優點，因為我認為就算是一些不常出現的極值，還是整體資料的一部分，所以如果為了建出理論的完美模型而拾棄那些極值，反而是和現實生活不合的情況。因此我是以離均的大小來建構出這個圖，所以就算是少數極值也只會分配在最外圍的圓上，不會對整體架構產生太大的影響。

統計方法命名:

Dartboard Statistics Method – 鏢靶統計方法