Use case or problem
Two issues:
-
Communication between plugins is quite poor. Example: TaskNote don’t work with tasks, one can’t import inline tasks into bases. It is not possible (afaik) to use spaced repetition card from another plugin, .. .
-
Importing external resources is hard: for external resources, plugin author have to build both the data extractor and the ui interface. Then, users can’t use another interface or pair it with other sources
Proposed solution
Adding a pretty simple api: plugins would be able to create virtual files, and other plugin would then read them.
A virtual file would be pretty much like a physical file:
- A title, a content
- A bunch of properties
- Metadatas (such as created date, ..)
- A flag to indicate that it is not an on-disk file
Plugins would then, at startup or later, register their files into the system.
Then, plugin such as bases, calendars, .. would display them like regular files, without caring about the plugin that created the file
Usescases examples
- A task plugin would export each individual task (even if those are inline tasks, or externally managed such as with CalDav), a flashcard plugin would export cards, a mail system may export mails, ..
- One could then import tasks (google events, inline tasks, caldav, ticktick) in bases, dataview, …
Concerns
Speed
There would be no io involved for this specifically, so it should be fast, even if there are thousands of small virtual files.
Complexity
For users: as it would basically be a bunch of files, it would be straightforward to use: you take your favorite query plugin, such as dataview, and tell it to filter files from a certain source.
For plugin developers: the api don’t have to be complicated: query systems from tags, .. already exists, and creating a file would just be filling a bunch of fields. Moreover, as plugins already have the datas, it should be possible to implement it on top of existing plugins.
For obsidian developers: Again, most systems already exists
Writable virtual files
It would require a callback from the virtual file source, otherwize the file would be read-only
Links
Links would require the source to give a stable id one way or another
Current workaround (optional)
- It is possible to put an adapter on top on the filesystem used by obsidian (see the Folder Bridge plugin). However, it is probably slower, and each plugin would need to use that trick.
- Each plugin can implement it’s own solutions, but it means that among
Related feature requests (optional)
Virtual notes for Bases would be solved by a simple plugin
Many requests around caldav support, bases supporting X