1  #+TITLE: Story 23 - Storage
 2  #+AUTHOR: Le’
 3  #+OPTIONS: date:nil
 4  #+LANGUAGE: en
 5  #+CATEGORY: core
 6  #+CATEGORY: lesec
 7  
 8  I've been thinking for some time about data stores, key stores, object
 9  stores.  Stuff saved on hard drives, USB-sticks, in a PKCS#11 vault.
10  I've also been thinking a bit more about containers (for which there
11  is a [[./story-8-Containers.org][previous story]]), 'cause I was thinking that a store is a kinda
12  container too, just with an additional reference to some external
13  storage.
14  
15  This has been a long and arduous time of thinking.  To see how this
16  could fit together with already existing stuff, and how it would
17  operate.
18  
19  For the longest time, I couldn't quite make it out...
20  
21  ...  then I started thinking, what if I looked at an Object Store as
22  just a Storage Reference that is somehow linked to existing objects,
23  with no further qualification?  In that case, wouldn't I just be left
24  with having to define the operations to transfer the Object to and
25  from the Storage Reference?
26  
27  That was an interesting thought, now I just wanted to see where it
28  would take me, and if that would seem robust enough, at least in
29  theory.
30  
31  So here's what I came up with.
32  
33  * Ideas
34  
35  - Storage Reference ::
36  
37    How to refer to a stored /Object/, i.e. give it an "address".  We
38    can let this be a simple string, to be passed around wherever it's
39    needed.  This could even be the /Object/ data itself, in some
40    serialised form.
41  
42  - Stored Object handling ::
43  
44    Retrieving objects, storing objects, creating objects, removing
45    objects, but most of all, associating objects with a *Storage
46    Rererence*.
47  
48    /This, along with *Storage Reference* (above) and with *Store
49    Session* (below), is further explored in [[file:story-24-Keeper.org::+TITLE: Story 24 - Keeper][Story 24 - Keeper]]/
50  
51  - Store handling ::
52  
53    A *Store* is a place where /Objects/ are stored in some form.  The
54    /Objects/ themselves may be hidden, but may also not, which allows a
55    directory of PEM files to be seen as a *Store*.  A *Store* would
56    would allow exploration, to find out what /Objects/ it holds.
57  
58    /This will be explored further in a future story/
59  
60  - Store Session ::
61  
62    A *Store Session* is an implementation specific thing that's the result
63    of interacting with a *Store*, where that interaction requires it
64    (typically, to unlock otherwise locked/hidden *Objects*).
65  
66    This is expected to be entirely handled by the implementation, so no need
67    to make it visible in Le'Sec Core (at least for now).  However, it may be
68    that an associated passphrase callback is needed.
69  
70  * Specifying a stored Object to be used
71  
72  Exactly how applications and higher level libraries should select which
73  Storage implementation to use at any moment is currently left to
74  experimentation.  Le'Sec Core only concerns itself with passing a
75  reference string, and leave the rest to the implementation.
76  
77  A /possible idea/ for the Le'Sec tools and application library could be to use
78  some sort of syntax that can include the Storage implementation name, like
79  (for the Storage implementation ~foo~ and a given ~reference~):
80  
81  - ~foo:reference~ (This could easily be made to look like a URI)
82  - ~foo::reference~
83  - ~{foo}reference~
84  
85  * Anything else?
86  
87  Yeah absolutely!  I've had some thoughts on in-memory stores, possibly
88  using the =data:= URI scheme (which is a bit wonky as URI schemes go,
89  but what can you do...), and have been wondering how to deal with
90  Objects in a Store that Le'Sec doesn't even have a type for, but that
91  the plugin may understand, and perhaps even the calling application.
92  There will need to be a way to pass them around...