If ids are unique strings, then why are `nodes` and `edges` arrays, as opposed to id-string-keyed maps?
JSON Canvas – An open file format for infinite canvas data
21–30 of 168 posts
Re: JSON Canvas – An open file format for infinite canvas data
#22If ids are unique strings, then why are `nodes` and `edges` arrays, as opposed to id-string-keyed maps?
A couple of other nit-picks:
- I'd like to see the `file` node have a mime type field.
- Why limit links to URLs, as opposed to URIs?
- You might want to put a version field in the top level!
Re: JSON Canvas – An open file format for infinite canvas data
#23I 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.
Re: JSON Canvas – An open file format for infinite canvas data
#24I would love to see this and excalidraw converge feature & spec wise.
Re: JSON Canvas – An open file format for infinite canvas data
#25I really like the idea of a format for interchange between infinite canvas apps, but the preset colors and list of node types makes this spec feel strangely opinionated. You could build something like Kinopio [1] but not much beyond that. It looks really promising though! I'm definitely interested in seeing this grow. [1] https://kinopio.club
Thinking about it, I'm not sure any interchange spec would leave useful room for innovation. This isn't like EPS or PDF or something where the kind of output is well-defined (printable graphics + text) and the innovation is in the editing interface. The innovation in canvas apps is surely in the semantics of the nodes themselves; but if you add some new node type with special behavior, how can you usefully export tha…
My very first thought about this format was that someone is definitely going to pervert it to be used as a graphics format, and for that it's woefully inadequate. I decided to hold my tongue since it's not the creators' fault that someone will misuse it, but I can totally see people adding optional ad hoc fields to nodes to allow for example all sorts of fancy line styles.
Re: JSON Canvas – An open file format for infinite canvas data
#26Is this infinite canvas similar to QGraphicsView?
I've been looking for a good equivalent to QGraphicsView and HTML Canvas is not it (HTML Canvas is a raster image, QGraphicsView is a size-independent fixed-sized, scrollable canvas with indexed objects).
Re: JSON Canvas – An open file format for infinite canvas data
#27Is there any control over the routing of the edges?
Re: JSON Canvas – An open file format for infinite canvas data
#28There's some questions about interoperability, which I imagine to be hard since any canvas app involves viewing and editing and probably has unique entities and approaches which other apps wouldn't be able to handle.
BUT, I imagine this being more useful for creating non-frontend tools. For instance a server that returns subsets of nodes for a particular viewport. Or something that may index nodes, or produce search results. Or tools that simply generates canvases from other data as a one-way operation.
Re: JSON Canvas – An open file format for infinite canvas data
#29Since a whiteboard is much more a visual thing, I imagine the spec should spend a lot of space defining the visual elements like specifying the control points of the Beizer curves because where a line is drawn and what it overlaps matters a lot on a whiteboard.
But to be a total downer, this spec looks like an extremely rudimentary graph file format, of which there are already like a hundred and all define more visual aspects than this spec.
Re: JSON Canvas – An open file format for infinite canvas data
#30I've worked a few jobs now where application data was stored in text files of various kinds (homegrown as well as well-defined formats, JSON included) and it pretty quickly becomes a mess when you start talking about modifying it over time, evolving its schema, validating it in the face of end-user edits, ensuring threads don't write to it concurrently, etc.
This strikes me as exactly the type of application data that would benefit from being represented in SQLite. Of course, JSON is a `JSON.parse` away, but now you're building your own...everything else. Storage/retrieval, validation, querying/filtering/indexing, graph traversal, etc. It's all yours.
There's so many benefits to building this kind of thing in SQLite. You get data validation, atomic transactions in memory and on disk, a high-level query interface, lazy loading (i.e., only load nodes at most 2 edges away), triggers (when I delete this node, automatically delete edges that point to it), and a stable on-disk format, to say nothing of the fact that SQLite itself is just about the most stable software there is.
By the way, no disrespect to JSON Canvas, it looks like good work, just trying to offer the perspective of someone who has done stuff like this in the past.