WhatwgStorage Whiteboard: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
| (3 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
Neil to impl core storage system, jst to impl security/access/scoping. vlad to advise, shaver to cheerlead. | |||
* Can we track "browser context" well enough? | * Can we track "browser context" well enough? | ||
** https://bugzilla.mozilla.org/show_bug.cgi?id=117222#c125 | ** https://bugzilla.mozilla.org/show_bug.cgi?id=117222#c125 | ||
* UI requirements? | * UI requirements? | ||
** need a storage limit (by domain and subdomain) | ** need a storage limit (by domain and subdomain) -- global limit for A2 | ||
** expiration policy? | ** expiration policy? (after A2) | ||
* domain hierarchy stuff? (see [http://groups.google.com/group/mozilla.dev.platform/browse_frm/thread/aafd263e23666ee/0a2c54c8c6c5754e?q=domain&rnum=1#0a2c54c8c6c5754e m.d.platform posting]) | * domain hierarchy stuff? (see [http://groups.google.com/group/mozilla.dev.platform/browse_frm/thread/aafd263e23666ee/0a2c54c8c6c5754e?q=domain&rnum=1#0a2c54c8c6c5754e m.d.platform posting]) | ||
* What subset? | * What subset? | ||
** 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) | |||
* 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] | |||
** darin: cookies have the notion of session only, which is not persisted. the web cache has the concept of "no-store". this storage system needs something like that too. web apps should be given a way to restrict storage to in-memory only. | |||
* globalStorage using mozStorage, simple table | |||
** look at what history guys did for fast domain-based lookup? | |||
Latest revision as of 22:47, 13 April 2006
Neil to impl core storage system, jst to impl security/access/scoping. vlad to advise, shaver to cheerlead.
- 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
- darin: cookies have the notion of session only, which is not persisted. the web cache has the concept of "no-store". this storage system needs something like that too. web apps should be given a way to restrict storage to in-memory only.
- globalStorage using mozStorage, simple table
- look at what history guys did for fast domain-based lookup?