GitBook: [#57] Added Roadmap Information

SUMMARY.md

@@ -42,5 +42,6 @@
 
 ***
 
+* [Roadmap](roadmap.md)
 * [Credits](credits.md)
 * [Sponsors](sponsors.md)

roadmap.md

@@ -0,0 +1,18 @@
+# Roadmap
+
+I maintain this to the best of my ability given my relatively limited spare time. However, I do have some plans for improvement in the future!
+
+Please do contribute (code or just opinions) if you would like to and have the time to!
+
+## Migrate to SQL internally
+
+Before v2, this plugin used an 'sqflite' database to store tiles. However, I removed this in order to add support for multiple stores.
+
+Whilst this impacted both functionality and performance positivley at the time, there are now bottlenecks caused by the reliance on the native filesystem. These include, but are by no means limited to:
+
+* Struggles with sanitizing the tile name to convert it to a file name that is suitable on every device - harder than you might think, given the large number of differing restrictions set by differing filesystems/operating systems.
+* Limitations to the speed of the import/export functionality: stores must first be compressed (and uncompressed on the other side) into a ZIP format. For a larger number of tiles, this can be quite slow!
+* Limitations to the speed of statistic fetching: reading each tile to find its length (size) and summing this up doesn't sound like it would take long, but it does. It's also quite memory inefficient. This was partially resolved by the statistic caching introduced in v5, but is not ideal.
+* The whole storage structure being easily edited and broken by a curious user. This also includes the fact that the bulk download functionality can very easily lead to copying: whilst keeping them as blobs in an SQL table won't stop this, it will make it significantly more difficult.
+
+Migrating to SQL won't be easy and will take time - I haven't even chosen a database package yet! Additionally, the non-asynchronus statistic getters are likely to have to be removed.

usage/integration.md

@@ -16,11 +16,11 @@ This method (and others) optionally take a `FMTCTileProviderSettings`. These con
 
 `FMTCTileProviderSettings` can take the following arguments:
 
-| API Parameter         | Type                                                 | Explanation                                                                          | Default                    |
-| --------------------- | ---------------------------------------------------- | ------------------------------------------------------------------------------------ | -------------------------- |
-| `behavior`            | ``[`CacheBehavior`](integration.md#cache-behavior)`` | Logic used for storage and retrieval of tiles                                        | `CacheBehavior.cacheFirst` |
-| `cachedValidDuration` | `Duration`                                           | Duration until a tile expires and needs to be fetched again                          | `const Duration(days: 16)` |
-| `maxStoreLength`      | `int`                                                | Maximum number of tiles allowed in a cache store before the oldest tile gets deleted | `0`: disabled              |
+<table data-card-size="large" data-view="cards"><thead><tr><th>Parameter</th><th>Description</th><th>Default</th></tr></thead><tbody><tr><td><code>behavior</code>: <a href="integration.md#cache-behavior"><code>CacheBehavior</code></a><code></code></td><td>Determine the logic used during handling storage and retrieval of browse caching</td><td><code>CacheBehavior.cacheFirst</code></td></tr><tr><td><code>cachedValidDuration</code>: <code>Duration</code></td><td>Length of time a tile remains valid, after which it must be fetched again (ignored in <code>onlineFirst</code> mode)</td><td><code>const Duration(days: 16)</code></td></tr><tr><td><code>maxStoreLength</code>: <code>int</code></td><td>Maximum number of tiles allowed in a cache store (deletes oldest tile)</td><td><code>0</code>: disabled</td></tr></tbody></table>
+
+{% hint style="warning" %}
+Note that using `maxStoreLength` can have a negative effect on performance, as sorting the tiles to find the oldest is (currently) expensive.
+{% endhint %}
 
 ### Cache Behavior
 

usage/roots-and-stores/README.md

@@ -44,9 +44,13 @@ Only use this if you cannot use asynchronous techniques in your current context,
 After this, you can chain any of the following members/accessors (each will be accessible on a Root, a Store, or both):
 
 {% hint style="success" %}
-Many of the methods and getters one level beneath the ones listed here, for example those under `manage`, have asynchronous versions which are recommended for performance.
+Many of the symbols one level beneath the ones listed here, for example those under `manage`, have asynchronous versions which are recommended for performance.
 
-To use them, if available, just add 'Async' to the end of the method/getter. For example, `manage.ready` and `manage.readyAsync`.
+To use them, if available, just add 'Async' to the end of the symbol. For example, `manage.ready` and `manage.readyAsync`.
+{% endhint %}
+
+{% hint style="warning" %}
+Avoid using the synchronus versions of these symbols: these may be removed in a future version. See [roadmap.md](../../roadmap.md "mention") for more information.
 {% endhint %}
 
 {% content-ref url="../integration.md" %}