rationale for config refactoring
authorDieter Plaetinck <dieter@plaetinck.be>
Mon, 11 May 2009 17:14:41 +0000 (19:14 +0200)
committerDieter Plaetinck <dieter@plaetinck.be>
Mon, 11 May 2009 17:14:41 +0000 (19:14 +0200)
docs/config-syntax

index 2315b6c..30cf91f 100644 (file)
@@ -35,4 +35,22 @@ spawn            <filename for process to start asynchronously>
 exit
 search           <string>
 
-The 'set' command may do more then just set the variable. eg 'set uri' commands will also cause uzbl to navigate to the uri.
\ No newline at end of file
+The 'set' command may do more then just set the variable. eg 'set uri' commands will also cause uzbl to navigate to the uri.
+
+
+
+Rationale. AKA "why not config files?"
+-> unify code to configure uzbl and to accept incoming commands
+-> no more code needed for config file parsing/handling
+-> runtime changing of configuration
+
+issues
+-> new instances (open link etc) need same config/state
+   solutions?
+   - serialize all state structs -> some libs available, could work. but:
+                                    - binary format not very user friendly
+                                    - not that easy (C has no introspection etc)
+   - iterate over state structs and generate appropriate commands to bring an instance in this state.
+     - plaintext :)
+     - user editable
+     - also useful for saving state if we need to update/shutdown/..
\ No newline at end of file