Thoughts on making Dataview its own app?

[classicrob]

I really like Dataview but at the same time feel as though when I use it, I add in this tension between the interoperability/portability of using markdown and the specificity of using Obsidian. Do you see a world where Dataview could in some way be generalized to any directory of markdown files instead of any directory of markdown files opened within Obsidian? What would it take to get to that world?

[srid]

I support prioritizing standards and portability, so that this idea (dataview) is not limited to Obsidian only. For example, srid/emanote#106

[blacksmithgu]

There is nothing about Dataview that is strictly bound to Obsidian; the vast majority of the code is wholly independent of any desired frontend (only the frontend rendering and the background indexing code interacts with obsidian). The main thing that dataview relies on for performance reasons is that it can run in the background and generate an in-memory index of all of your markdown files, as this is what makes queries fast.

Jumping from "dataview for obsidian" to "dataview for any markdown files" depends on how you handle your markdown files. A command-line daemon for the CLI savvy is doable with some node magic; adding support to another markdown viewer mainly depends on how well the given viewer supports plugins.

[srid]

What are you thoughts on maintaining an independent feature/syntax spec that doesn't assume any specific implementation (nodeJS in this case)? For eg., the app (Emanote) I linked to above is written in Haskell, acting as a static site generator for Obsidian'ish markdown notes; and if I'm to implement something like 'dataview' in Emanote, it would be nice to use this spec as a reference.

[blacksmithgu]

I'm not opposed to it; if I were to do so I would likely need to expand the spec to include features I'm working on but haven't completed (UNION statements, more general FROM blocks which allow expressions, subqueries), since otherwise the spec would likely change frequently and be annoying from an implementation perspective.