Add Odilia caching idea

ideas/index.md

@@ -340,4 +340,42 @@ Security is *always* a concern, no matter how remote the possibility is of some
 Meme Template Recognition (MTR) should OCR the plain text found in a meme, and also lookup the closest match in terms of which meme template is used.
 Have each template with a description of the meme and how it is generally used.
 
+## 13. Odilia Ideas
 
+[Odilia](https://odilia.app) is a new Linux screenreader project.
+I have some ideas about it to write down here.
+
+### 13.1 Cache
+
+A cache would be relatively simple to implement, or so I think right now.
+If I watch the output of `dbus-monitor` when Orca is running and it shows me all my accessibility events, I can see that it basically boils down to extremely simple events:
+
+* An element has been removed.
+* An element has been added, with XYZ as its parent.
+* An element's text has been changed/deleted; it is now "XYZ".
+
+I think it would be (fairly) easy to cache the entire a11y tree of at least a web container, but maybe other types of interfaces as well.
+I would not store all information about each item.
+Only critical information to VASTLY speed up things like structural navigation.
+
+For example:
+if you look for a next header in a web document by pressing "h" in browse mode, a DBus lookup for every element's parent, AT-SPI role, and children needs to be made over DBus.
+If it could be possible to do these intensive tasks within native Rust code, without calling out to DBus, this could be a game changer.
+It would make it INSANELY fast for structural nav, and if it needs to call out to DBus for the text, that's fine by me.
+Storing text could potentially balloon the memory usage pretty hard anyway, so I'm not sure that's a great idea.
+
+So, store some basic info like role, id, parent id, ids of children, maybe a few more. All in all it should represent less than 50 bytes on average.
+This means that even with a million items, which I hope someone would never be so unfortunate as to need that many, it could all be contained safely within about 50MB of RAM.
+It would be worth the tradeoff in nearly every single case I can think of.
+And, even if we added, say a 100-byte string buffer for smaller strings to be cached.... Then we'd still be around 150MB of ram for 1 million elements cached---I would like to point out that this is stupendously high, and is fairly impractical to begin with.
+I think the memory-time tradeoff will win in this case.
+
+
+So, store some basic info like role, id, parent id, ids of children, maybe a few more. All in all it should represent less than 50 bytes on average.
+This means that even with a million items, which I hope someone would never be so unfortunate as to need that many, it could all be contained safely within about 50MB of RAM.
+It would be worth the tradeoff in nearly every single case I can think of.
+And, even if we added, say a 100-byte string buffer for smaller strings to be cached.... Then we'd still be around 150MB of ram for 1 million elements cached---I would like to point out that this is stupendously high, and is fairly impractical to begin with.
+I think the memory-time tradeoff will win in this case.
+
+At the time of writing, the Odilia screenreader is not far enough along to either benchmark or implement these features, but I just need to write them down before I forgot why it was a good idea.
+I think, personally, that a small string buffer for practically-sized strings would be ideal, as this could also speed up potential addons (think control+f but for an entire GUI application, not just the web) and this would still approach fair RAM usage and impeccable speed---although I do understand that this view may go a little far for the other two developers working on that project. We'll see.