WhatwgStorage Whiteboard: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
| Line 9: | Line 9: | ||
** no DOM object or JS object auto-serialization | ** no DOM object or JS object auto-serialization | ||
** jst to propose the removal of key enumeration to whatwg list (security reasons) | ** jst to propose the removal of key enumeration to whatwg list (security reasons) | ||
* sessionStorage using in-memory hash or just another table? | |||
** vlad: no on-disk storage for security reasons? | |||
** shaver: what about session saver? (what does it do for session cookies?) | |||
** spec suggests persistence of session data in this case: [http://www.whatwg.org/specs/web-apps/current-work/#the-sessionstorage 4.9.3] | |||
* globalStorage using mozStorage, simple table | |||
** look at what history guys did for fast domain-based lookup? | |||
Revision as of 20:33, 12 April 2006
- Can we track "browser context" well enough?
- UI requirements?
- need a storage limit (by domain and subdomain) -- global limit for A2
- expiration policy? (after A2)
- domain hierarchy stuff? (see m.d.platform posting)
- What subset?
- no DOM object or JS object auto-serialization
- jst to propose the removal of key enumeration to whatwg list (security reasons)
- sessionStorage using in-memory hash or just another table?
- vlad: no on-disk storage for security reasons?
- shaver: what about session saver? (what does it do for session cookies?)
- spec suggests persistence of session data in this case: 4.9.3
- globalStorage using mozStorage, simple table
- look at what history guys did for fast domain-based lookup?