Re: Application resource storage

[Ted Zlatanov <tzz@lifelogs.com>]

On Tue, 29 Mar 2011 21:34:05 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>> Even though this means duplicating data, somewhat, I think we should
>> keep normal application defaults separate from secret credentials.

LMI> Which reminds me of something we discussed half a year ago: Storing
LMI> responses to questions.

LMI> Today, if Emacs prompts the user for something, and it's something that
LMI> should be remembered always by Emacs, Emacs uses custom to save the
LMI> value.  This works well for things that map nicely to one single
LMI> variable.

LMI> But if the question is of the kind "do you want to use port 587 when
LMI> connecting to smtp.gmail.com?", then that doesn't really map
LMI> straightforwardly to a simple variable.  It might map to an alist of
LMI> some kind, but the user may set that alist somewhere else, which makes
LMI> all this kind of tricky.

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?)

Also assistant.el is currently a full-buffer application but it could be
implemented as a prompting interface as well to make these queries less
distracting.

LMI> Wouldn't it be nice if Emacs had a way to store these values in a
LMI> simpler manner without encroaching on the variable space?

LMI> That is, I'm kinda thinking of something like

LMI> (store-value "smtpmail-smtp-server-smtp.gmail.com-port" 587)

LMI> The first is a token uniquely identifying the resource, and the second
LMI> is the value.

LMI> These could be stored in ~/.emacs.d/resources, which could then be
LMI> queried by the applications.

LMI> Does this exist already?  Stupid idea?

It seems like an application-specific thing.  I would implement it as an
assistant.el facility to save the walkthrough and to query nodes in it.

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.

Ted