Possible feature: Local data storage

[kitesurfai]

I would be interested in helping integrate this with dendron. Is there any appetite for that type of feature? Specifically with respect to efficient local data storage formats that can be interfaced with the local markdown editing experience in vscode.

[jaywonchung]

Hi @james-murdock-graham. I'm personally not familiar with Dendron, but I've recently heard of various needs to integrate reason with other reference management software or note-taking apps. If someone needs that integration, I can definitely chime in and help clarify things about how Reason works.

Currently, all of Reason's states (i.e., the paperbase) is just a single file: https://github.com/jaywonchung/reason/blob/master/examples/metadata.yaml
Paths to the paper PDF (doesn't really have to be PDF as long as the viewer can open it) and the markdown note attached to the paper (doesn't really have to be markdown as long as the command line editor can open it and you don't plan to use the printf command) are all stored in the YAML file.

[kitesurfai]

Hi @jaywonchung that clarifies things significantly, thank you for the quick reply. I don't see an ISSUE_TEMPLATE, do you have any preference as to the structure of contributions, if any? I might take a stab at it and cut a quick proof of concept PR if you're open to it.

[jaywonchung]

In general, I would want to avoid making reason and its existing commands less generic over the software choices of the user. So, if we were to integrate reason with a specific storage backend (not sure if this phrase accurately captures the goal of the integration), I think there should be an adaptor layer that translates the current YAML-based paperbase to and from Dendron's format (for initialization), and the user, even if they were not using Dendron as their storage backend, can explicitly opt in by turning on something like:

[storage]
backend = 'dendron'

which will also check whether the user installed Dendron (or any other necessary infrastructure) on startup.
I believe the adaptor layer should be able to translate from Dendron to YAML-based because the user might hop from one storage backend to another, in which case their Dendron format should first be translated into YAML (a shared representation), and then to the new storage backend's format.
When storage.backend is set and translation is done, I think the new storage backend can just replace the YAML-based paperbase and directly work on Dendron's format, while ensuring that all (or most) existing reason commands work.