Redis thoughts in future troggle database

handbook/troggle/trog2030.html

@@ -123,6 +123,16 @@ but doesn't really change anything from the perspective of our need to stop user
 everything in in-memory dictionaries we may need to write our own asyncio python to do that synchronization. That would be a Bad Thing as 
 we are trying to make future maintenance easier, not harder. But it looks like Redis could be the solution for us.
 
+<p style = "margin-left: 5em; margin-right: 3em">  [ Redis does multi-user concurrency (which is what we need), but most people don't use it like that.
+Nearly everyone who uses Redis with Django uses it as a page cache, not as the fundamental store. So public
+experience is likely to be less useful than we may hope. Learning to use Redis would probably also mean getting to grips with
+Django's <a href="https://docs.djangoproject.com/en/dev/topics/cache/#redis">existing cache system</a>, 
+which is complex and which we don't use.
+<br>
+NB We do cache one page per expedition, but explictly in our own python code. So this is a per-process cache which is good for one
+person's intensive use, much like Django's 
+<a href="https://docs.djangoproject.com/en/dev/topics/cache/#local-memory-caching">Local-memory caching</a> ]</p>
+
 <h3>Things that could be a bit sticky 2 - front-end code</h3>
 <p>There is not yet a front-end (javascript or <a href="https://en.wikipedia.org/wiki/WebAssembly">WebAssembly</a>) framework on the client, i.e. a phone app or webpage, which is stable enough for us to commit
 effort to (we managed to remove all the jQuery by using recent HTML5 capabilities). Flask looks interesting