Gitweb links:
...log
http://git.netsurf-browser.org/netsurf-wiki.git/shortlog/15cdd4abc5068576406f6566e3d3c1666a2dc5c1
...commit
http://git.netsurf-browser.org/netsurf-wiki.git/commit/15cdd4abc5068576406f6566e3d3c1666a2dc5c1
...tree
http://git.netsurf-browser.org/netsurf-wiki.git/tree/15cdd4abc5068576406f6566e3d3c1666a2dc5c1
The branch, master has been updated
via 15cdd4abc5068576406f6566e3d3c1666a2dc5c1 (commit)
from 5e7d2d79625b8a968c06478a7cc6946d1daaaba0 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commitdiff
http://git.netsurf-browser.org/netsurf-wiki.git/commit/?id=15cdd4abc5068576406f6566e3d3c1666a2dc5c1
commit 15cdd4abc5068576406f6566e3d3c1666a2dc5c1
Author: Daniel Silverstone <[email protected]>
Commit: Daniel Silverstone <[email protected]>
More notes
diff --git a/developer-weekend/sep-2017.mdwn b/developer-weekend/sep-2017.mdwn
index d59681f..f7305fa 100644
--- a/developer-weekend/sep-2017.mdwn
+++ b/developer-weekend/sep-2017.mdwn
@@ -74,6 +74,8 @@ Topics
resources.
* We'd like to buy a pair of WD Gold 1TB drives (rough cost 140 UKP total)
so that Phoenix isn't running on pre-fail age drives.
+ * We investigated cloud/hosted servers, sadly it's super-expensive compared
+ to some new disks for the free hosting we have.
* Decision was: Michael, Vince, and Daniel will share the cost if the
society lacks the funds. Vince will buy drives and begin the replacement
process. Ideally ASAP.
@@ -84,9 +86,83 @@ Topics
* Auto-scroll to last position during history navigation
* See below
-* The "What's Next?" of Javascript
-* URLdb/Cookies
* Breaking changes and 4.x
+ * We have defined 'major' changes as anything large (e.g. new layout would
+ be major)
+ * Also 'major' changes include on-disk format changes. This means that
+ we'll forward-migrate where possible, but make no guarantees about going
+ backwards. Migration will be explicit and cancellable on startup.
+ * Content migrations must be such that if you run an old version, it won't
+ pick up old content by default.
+
+* What's left to go in to 3.7
+ * Michael's searching for hotlist (treeview search)
+ * Vince's fixes for bitmaps in local history
+ * History navigation keeping scroll offsets
+ * Logging rework fallout
+ * General memory leak fixes where possible
+ * Aiming for 3.7 release handle crankage around Saturday September 23rd.
+
+* URLdb/Cookies
+ * URLdb is a mess. We knew that, there's nothing new there.
+ * We'd like to replace it, in its entirety, including on-disk formats.
+ * It should be split into a proper cookie jar, and a metadata store keyed
+ by URL.
+ * For the cookie jar, there is an RFC for cookie handling, lots of useful
+ information and links on
+ <https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies>
+ * For the "URL database" we need to store arbitrary and changeable sets
+ of key-to-value mappings, some of which need to persist, some of which
+ are to be RAM-only.
+ * If we add scope to the 'key' such that we can have localstorage as a
+ scope then we can put local storage <https://www.w3.org/TR/webstorage/>
+ into the same DB.
+ * Potential implementation strategy:
+ * Use a journalling approach (where the entries are
+ create/change and delete commands) storing the journal as the URLdb
+ replacement.
+ * The primary key into the DB is based on `nsurl`.
+ * We will reuse the `resource:` scheme for "internal" storage.
+ (e.g. session state, disk cache indices etc)
+ * The "value set" is a bag of triples. (`scope`, `key`, `value`) where
+ the scope is one of an enumeration (e.g. `localStorage` or `urldb`)
+ the key is a simple utf-8 string, and the value is an arbitrary set
+ of bytes (up to 4GB). (thus is stored as bytes+u32_length).
+ * We need the in-memory representation to support the following
+ efficiently:
+ 1. Counting of key,value pairs in a given scope for a given url
+ 2. Indexing a given (url,scope) pair by integer stably
+ 3. Indexing a given (url,scope) pair by key name
+ 4. Construction of journal entries (on changes)
+ 5. Completion of url strings
+ 6. Distinguish between content which can be persisted and that
+ which should not.
+ * The "clean" writeout should ensure that everything necessary for the
+ session restoration gets written out first, and then a marker is put down
+ which the readback code can use to kick off an async load of the rest of
+ the data.
+ * File format should be binary, and be robust (length, kind, checksum,
+ payload).
+ * Plausible things to layer on this generic storage are:
+ * URLdb replacement
+ * Session management
+ * LocalStorage
+ * Cookie jar
+ * File-based cache backend (indices)
+ * User options.
+ * Multiplicity (no single core)
+ * Proper testing for this.
+
+* The "What's Next?" of Javascript
+ * We do all the other stuff first, since it all has JS implications
+ * We need to update the IDLs and include more parts (e.g. LocalStorage,
+ CSSOM, etc)
+ * nsgenbind - should it do more automatic generation? If so how?
+ * Fix nsgenbind's `#file` `#line` stuff so that debugging works better.
+ * Fill out more of the bindings.
+ * So much of libdom needs enhancing too.
+
+
Frontends
=========
@@ -296,7 +372,7 @@ Bug fixes
* Michael found and fixed a GTK core window issue where modifier keys were not
getting passed with mouse clicks (release), only with press. This prevented
Hotlist/Bookmarks entry editing.
-
+* Daniel fixed a set of leaks from the logging layer.
Next time
=========
-----------------------------------------------------------------------
Summary of changes:
developer-weekend/sep-2017.mdwn | 82 +++++++++++++++++++++++++++++++++++++--
1 file changed, 79 insertions(+), 3 deletions(-)
diff --git a/developer-weekend/sep-2017.mdwn b/developer-weekend/sep-2017.mdwn
index d59681f..f7305fa 100644
--- a/developer-weekend/sep-2017.mdwn
+++ b/developer-weekend/sep-2017.mdwn
@@ -74,6 +74,8 @@ Topics
resources.
* We'd like to buy a pair of WD Gold 1TB drives (rough cost 140 UKP total)
so that Phoenix isn't running on pre-fail age drives.
+ * We investigated cloud/hosted servers, sadly it's super-expensive compared
+ to some new disks for the free hosting we have.
* Decision was: Michael, Vince, and Daniel will share the cost if the
society lacks the funds. Vince will buy drives and begin the replacement
process. Ideally ASAP.
@@ -84,9 +86,83 @@ Topics
* Auto-scroll to last position during history navigation
* See below
-* The "What's Next?" of Javascript
-* URLdb/Cookies
* Breaking changes and 4.x
+ * We have defined 'major' changes as anything large (e.g. new layout would
+ be major)
+ * Also 'major' changes include on-disk format changes. This means that
+ we'll forward-migrate where possible, but make no guarantees about going
+ backwards. Migration will be explicit and cancellable on startup.
+ * Content migrations must be such that if you run an old version, it won't
+ pick up old content by default.
+
+* What's left to go in to 3.7
+ * Michael's searching for hotlist (treeview search)
+ * Vince's fixes for bitmaps in local history
+ * History navigation keeping scroll offsets
+ * Logging rework fallout
+ * General memory leak fixes where possible
+ * Aiming for 3.7 release handle crankage around Saturday September 23rd.
+
+* URLdb/Cookies
+ * URLdb is a mess. We knew that, there's nothing new there.
+ * We'd like to replace it, in its entirety, including on-disk formats.
+ * It should be split into a proper cookie jar, and a metadata store keyed
+ by URL.
+ * For the cookie jar, there is an RFC for cookie handling, lots of useful
+ information and links on
+ <https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies>
+ * For the "URL database" we need to store arbitrary and changeable sets
+ of key-to-value mappings, some of which need to persist, some of which
+ are to be RAM-only.
+ * If we add scope to the 'key' such that we can have localstorage as a
+ scope then we can put local storage <https://www.w3.org/TR/webstorage/>
+ into the same DB.
+ * Potential implementation strategy:
+ * Use a journalling approach (where the entries are
+ create/change and delete commands) storing the journal as the URLdb
+ replacement.
+ * The primary key into the DB is based on `nsurl`.
+ * We will reuse the `resource:` scheme for "internal" storage.
+ (e.g. session state, disk cache indices etc)
+ * The "value set" is a bag of triples. (`scope`, `key`, `value`) where
+ the scope is one of an enumeration (e.g. `localStorage` or `urldb`)
+ the key is a simple utf-8 string, and the value is an arbitrary set
+ of bytes (up to 4GB). (thus is stored as bytes+u32_length).
+ * We need the in-memory representation to support the following
+ efficiently:
+ 1. Counting of key,value pairs in a given scope for a given url
+ 2. Indexing a given (url,scope) pair by integer stably
+ 3. Indexing a given (url,scope) pair by key name
+ 4. Construction of journal entries (on changes)
+ 5. Completion of url strings
+ 6. Distinguish between content which can be persisted and that
+ which should not.
+ * The "clean" writeout should ensure that everything necessary for the
+ session restoration gets written out first, and then a marker is put down
+ which the readback code can use to kick off an async load of the rest of
+ the data.
+ * File format should be binary, and be robust (length, kind, checksum,
+ payload).
+ * Plausible things to layer on this generic storage are:
+ * URLdb replacement
+ * Session management
+ * LocalStorage
+ * Cookie jar
+ * File-based cache backend (indices)
+ * User options.
+ * Multiplicity (no single core)
+ * Proper testing for this.
+
+* The "What's Next?" of Javascript
+ * We do all the other stuff first, since it all has JS implications
+ * We need to update the IDLs and include more parts (e.g. LocalStorage,
+ CSSOM, etc)
+ * nsgenbind - should it do more automatic generation? If so how?
+ * Fix nsgenbind's `#file` `#line` stuff so that debugging works better.
+ * Fill out more of the bindings.
+ * So much of libdom needs enhancing too.
+
+
Frontends
=========
@@ -296,7 +372,7 @@ Bug fixes
* Michael found and fixed a GTK core window issue where modifier keys were not
getting passed with mouse clicks (release), only with press. This prevented
Hotlist/Bookmarks entry editing.
-
+* Daniel fixed a set of leaks from the logging layer.
Next time
=========
--
NetSurf Developer Wiki Backing Store
_______________________________________________
netsurf-commits mailing list
[email protected]
http://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/netsurf-commits-netsurf-browser.org
