有必要使用一个 Browser 端的存储方案吗？

最近发现一个 Javascript 写的 SQL 引擎和存储方案，觉得有点意思：
Sysbotz 2.0 - JavaScript Database
AJAX MAssive Storage System (AMASS)
TrimQuery
AMASS 是用 flash 来做存储，如果Browser 端的存储真的有广泛的需求的话，也许扩展 Javascript 才是更好的办法。
这是在 Google 搜索 "javascript database" 发现的，如果谁有新的发现，敬请共享。
不知道有谁在实际项目中应用过此类方案？

说一下第一印象：

在JSP里写SQL，就已经是罪过了。在JavaScript里写SQL，似乎路子很邪啊。

赫赫，严重了。
Browser端存储，对于离线操作还有有价值的。这本是RIA对比RCP的一个软肋。

存储可以，但是以SQL方式存取，我认为比较不爽

不采用类SQL的方式，你有更好的建议？

根本还是操作javascript对象。感觉也没必要。

xml与javascript对象，谁有优势还难说。
毕竟javascrpt支持XQuery是比较不错的。比sql强多多。

没错，长期来看，俺也看好XML。但是与比较陡的学习曲线相比，类SQL的方法，也不失为一种快捷的方法。

实际情况是，做一个 B/S 的连锁超市 POS 销售前端，数据库在总部，商品调价在总部。如果每扫描一次商品条码就从总部读一次，效率很低(主要是实际的网络情况造成的)，所以需要一个 Browser 端的缓存方案，来缓存商品信息，每次扫描商品条码只需要从 Browser 里读取数据即可，另外定时从总部更新的商品数据(仅仅获取需要更新的部分，不是重读整张表)。当网络意外中断时，也可以继续销售。TrimQuery 只是一种查询方案，XQuery 应该也是查询方案吧，但是仅仅有查询方案不够，还需要 Browser 端的存储方案，当Browser  关闭后再打开时即使脱机仍然有数据进行工作。Browser 可以缓存网页、图片、JS 脚本，不知道有没有缓存数据的功能？(有人会说可以用 XML页面来缓存数据，但是怎么能够实现每次从总部只获取需要更新的部分，而且保持浏览器重新打开时又有效呢？)
又联想到一个问题，比如 Gmail 和 Writely，虽然他们有定时保存的功能，但前提是必须在线，脱机的情况下是无法保存的。 如果要实现脱机的情况下数据存储，还得依靠 Flash 等插件，或者 Java Web Start 等等，单单依靠 Browser 和 Javascript 目前似乎还不行。

如果非要基于html＋javascript来实现一个离线应用的本地存储，可以在本地给远程域设置一个信任授权，通过js控制ADO操作本地的access或者file。实际上，我们在dao这一层（或service层）分别实现一个远程dao和本地dao，上层代码就可以不用去理会是在线还在离线的区别了。

dao或service层不都是在server端麽？离线了还能访问?不是很明白。