之前一直在研究 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 中到底提到了什麼樣子的新型存取機制？原本可以歸類為下面三類：
- Session Storage
- Local Storage
- 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 的研究，歡迎留言指教 :]