Re: Application resource storage

[Ted Zlatanov <tzz@lifelogs.com>]

On Tue, 29 Mar 2011 22:14:11 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> I think you're describing an assistant.el walkthrough.  Right now the
>> assistants store their return in an artificial data structure but the
>> walkthrough with the user decisions and answers could *be* the data
>> structure (it's a decision tree, right?)

LMI> Yes, that would be a use case.  There are other things that this could
LMI> be used for that I've been missing -- for instance, now when nnimap
LMI> connects to a server, it tries both the imap and the imaps port.  If
LMI> nnimap could stash what the successful port was, and try that first the
LMI> next time, the next startup would be slightly faster.

LMI> Not particularly essential, but there's a lot of stuff like that that
LMI> could be done trivially if there was a place to stash this data...

Something like:

(preferred (imap (servers ("serverA" :port 587)
                          ("serverB" :port 1957))))

would be a nice way to remember this data.  The trick is to make this
data also the one that an assistant.el walkthrough would generate.

>> As a global Emacs facility it would be easy to make all these strings
>> part of a big global-registry alist, which can then be customized and
>> saved independently.  But I think it would squash the decision tree from
>> assistant.el into unwieldy string representations of the nodes and edges.

LMI> True.  But it's basically what Firefox does with its data, if you look
LMI> under about:config.

I think that would be a step backwards considering the available Lisp
facilities.  It would be pretty easy to generate these strings
dynamically and let the user edit them:

Prefs -> IMAP -> Servers -> [serverA] -> [port 587]
                         -> [serverB] -> [port 1957]
                         [+]

or some such interface.  But going backwards, where we decide on these
magical strings to express "the port and name for the Gnus IMAP serverA"
and only store the strings, is harder and less flexible because you have
to write the printer and the reader+parser.

Ted