obsidian-api VS go-sqlite

I really like that you commit to keep this stable and open.

Do you plan to make the TypeScript definition part of this new site?

https://github.com/obsidianmd/obsidian-api/blob/master/canva...

For me it's easier to read TS format.

The Canvas feature is a custom file format, but they published the format here: https://github.com/obsidianmd/obsidian-api/blob/master/canva...

If Obsidian goes under or you want to migrate at least your data isn't lost.

Obsidian is closed source so you won't be infringing their copyright by incorrectly getting/copying their code within your code. I don't believe they have any software patents (too small a company), and the canvas data format is available under MIT license (https://github.com/obsidianmd/obsidian-api/blob/master/canvas.d.ts). Even if you decided to reproduce their plugin APIs (so that existing Obsidian plugins could be reused with your software), you'd be fine per https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_Inc. (but their API definition is under MIT license anyway: https://github.com/obsidianmd/obsidian-api/tree/master)

I would start with with the obsidian api docs and the obsidian plugin docs then feed it into a gpt document loader and ask gpt the same thing you asked here. Obsidian offers a couple different “talk to your notes” plugins using gpt (all you need is an open ai api key) if you’re looking for a streamlined “ai document loader” you could just copy and paste the info into a new note once you have the plugin installed.

In any event, there are no CLI flags to do that at the moment. The canvas format is very new, and not part of the standard markdown format. There is a public specification for it, but it's up to developers to make applications supporting it.

Canvas has been an open standard since its release.

As far as I know, any API that can be used by end users and plugin developers (as described in the previous post) is considered public. You can find the API repo here and definitions in this file.

The .canvas format is a simple JSON-based format that is designed to be easy to parse. We've already seen several plugins leverage this and hope to see even more tools outside of Obsidian. You can see the spec here.

Check out https://github.com/zombiezen/go-sqlite if you're interested in trying out Sqlite in Go again. Nice interface, negligible compile time impact, fast, compiles without CGO. It's very comfortable.

I agree that going from text to sqlite is a bit of a hurdle, especially if you're not writing C :)

struggling figuring out how to make my cgo sqlite cross-compile to Windows

Plenty of people trying to fix that.

There's at least:

https://modernc.org/sqlite

Then there's https://github.com/zombiezen/go-sqlite that actually builds https://crawshaw.io/sqlite on top of modernc.

And there's mine that has both a low level and a database/sql driver builds and runs everywhere Go does: https://github.com/ncruces/go-sqlite3

There are several different Go bindings for SQLite. I maintain https://pkg.go.dev/zombiezen.com/go/sqlite

I like and use https://github.com/zombiezen/go-sqlite for CGo-free SQLite. It avoids some of the problems database/sql has, discussed here: https://crawshaw.io/blog/go-and-sqlite.

> C libraries are required to interact with SQLite

Or: modernc.org/sqlite (https://github.com/zombiezen/go-sqlite), "an automatically generated translation of the original C source code of SQLite into Go"

https://pkg.go.dev/modernc.org/sqlite via https://pkg.go.dev/zombiezen.com/go/sqlite

modernc.org/sqlite provides a database/sql driver, but does not (currently) provide an easy way to get at the more advanced functionality of SQLite, like streaming blob I/O or user-defined functions. David Crawshaw has argued that the database/sql API is not a good fit for SQLite, which is how crawshaw.io/sqlite came about.