Replies: 2 comments 1 reply
-
Hi, thanks for your interest! I had a very similar motivation in developing it to integrate Trilium with other applications. I took a good 8 months of considering various options for filesystem sync, and came to the conclusion that it just doesn't make sense to attempt supporting an arbitrary Trilium note hierarchy, especially the "clone" feature. Rather, it makes more sense to have subtrees in Trilium which map to a specific directory on a filesystem, with the constraint that within that subtree there are no clones. Additionally, representing a note tree in a specific filesystem format doesn't quite feel like the job of this project -- rather, this project should strive to support creation of general-purpose "bridges" between Trilium and other applications, only one of which is some kind of filesystem store. I'm envisioning a general-purpose way to develop drivers which would map a Trilium note to/from an external application. You would implement a Python snippet which would do things like update/access attributes and content per note using the TriliumAlchemy API, and update/access an external application accordingly. These bridges would then be configured using probably a .yaml file which specifies:
There would ideally be general-purpose sync logic which resolves changes (it would save a backup of the last synced hierarchy state for comparison). In the event of conflicting changes, it would just raise an error for the user to resolve them manually. But initially, "one-way" sync should be pretty simple. Regarding the filesystem format, I've started a project called Protium which allows you to define data models in Python and populate the data from a filesystem in a specific format. There's a default way to extract/update model data from the filesystem, but the model can implement custom logic to load data from a file/folder as well. There's a .yaml file containing model fields, which could readily map directly to Trilium attributes with a bit of custom code -- a bridge driver for Protium. I've got a working prototype of building a database using Python classes (leveraging Pydantic models) populated with data from a filesystem hierarchy. The format is pretty similar to what I had proposed in Filesystem note specification. There's a lot of work remaining, but with a bit more polishing I could publish an early version with limited features for experimentation. There will be some extra boilerplate code required which will eventually be taken care by the framework. Also currently models can't reference other independent models (equivalent to a Trilium relation), only compose models within models. The name Protium is in fact inspired by Trilium; the progression was Trilium → Tritium (hydrogen-3 isotope) → Protium (hydrogen-1 isotope). Idea is to reflect that it was designed from the ground up to be general-purpose, but easy to map to/from Trilium (with some constraints regarding clones). About the read-only fields, I'll just need to flip a switch to reflect what's now supported in ETAPI -- thanks for pointing that out. I'll push a release to resolve that, hopefully within a couple days. |
Beta Was this translation helpful? Give feedback.
-
Once again, thanks for a detailed response! I look forward to perusing the Filesystem note specification when I have time for attention. I share the uncertainty over a filesystem hierarchy that maps 1:1 to note hierarchy, especially in the long term. At base there is a fundamental mismatch of data types with consequent tension across the gap. Complexity can be pushed up/down, where it might be less obtrusive and beneficial for workflow X, but not entirely away. On the clones front specifically, a lot of complexity dissolves if you take a starting point of "filesystem must support and use hardlinks". All major OSes do, but it does require elevated permissions and skill from the user, which is a large narrowing (on Windows especially). A decade and more ago I was vehement "my new KB platform must be filesystem first"; today I'm lenient on that front, so long as the db is sqlite - because I trust interfaces to it will last as long as computers do. (SQlite as application file format is simultaneously persuasive and inspiring.) For me, today, I think I'd be happy with filesystem-to-Trilium mapping for input, and other fit for purpose mappings for output (e.g. blog posts for a static website; one-off migrating to a new tool du jour, ...). |
Beta Was this translation helpful? Give feedback.
-
My interest in trilium-alchemy is for importing a large body of pages from the various other applications I've used over the years. Naturally the Filesystem notes and it's "proposed files first" approach is interesting. What's the status of that effort?
sub-thread: In my prior experiments in this arena I quickly ran into the issue of needing independent control of the
dateCreated
and related attributes - they need to be the content date, not the import date (thread). However in the TA api docs I see the date fields are are readonly. How firm is that?Beta Was this translation helpful? Give feedback.
All reactions