Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JSON Canvas – An open file format for infinite canvas data

jsoncanvas.org

Post reply on HN
Print view View original

51–60 of 168 posts

Re: JSON Canvas – An open file format for infinite canvas data

#51

Post by jakelazaroff »

simonw wrote: post #31

It would be neat if the README or spec included links to some real-world examples of files - would be easier to start playing with building simple tools on top of this if there was already an example file to start experimenting with, without me having to learn Obsidian first. UPDATE: Figured out how to create one: 1. Install and then open Obsidian 2. Click the "Create new canvas" icon - third down of the icons on the…

If you hit "toggle output" on the bottom right, it shows a JSON Canvas representation of the page's content.

Re: JSON Canvas – An open file format for infinite canvas data

#52

Post by asa400 »

simonw wrote: post #32
asa400 wrote: post #30

I'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 tha…

I'm usually the first person to suggest SQLite for just about anything, but in this particular case I do feel like JSON is a better default format. Interacting with SQLite from different programming languages is easier than most other formats, but you still need a SQLite binding. They're available for every language but that's still a not-completely-trivial dependency. I expect most tools that people build against JS…

Valid points and I generally agree! I think you're probably right that the SQLite dependency is possibly too much for some applications to pull in, though I will ask why we're so often willing to pull in more or less anything else regardless of weight (DOM manipulation, state management, animation, etc.) but a robust data layer is often a bridge too far. I wish I knew why this is, as it seems to be one of the larger cultural differences between folks who work mainly "on the backend" and "on the frontend".

> Also: SQLite files aren't very easy to diff, so they're not great for collaboration in version control. JSON is better for that.

Yeah, if we're talking about diffing the literal file itself, then that changes things. At that point, we're not just talking about a storage format, we're talking about interchange as well. In that case I'd ask - of course this is application specific, not general - what data are we putting on the wire? Where does that data live?

For example, if the main state state lives in a your browser instance, and you ship updates (i.e., "CREATE", "EDIT", "DELETE" or some such) back and forth between collaborators, then diffing the state of whatever you have is fairly easy, SQLite or JSON or whatever else. But if we're shipping the actual file itself over the wire or attempting to version control it, then you're absolutely right and diffing the SQLite file is inferior.

There are some interesting tradeoffs in this space. This is a fun discussion!

Re: JSON Canvas – An open file format for infinite canvas data

#53

Post by asa400 »

chrisweekly wrote: post #38
asa400 wrote: post #30

I'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 tha…

Crucial context: its provenance is embedded infinite canvas in Obsidian (amazing markdown-based notes app++), which supports JS but has no external datastore per se. SQLite is fantastic, but inappropriate for this use case.

Oh I read the post and a few of the other linked posts so I'm aware. If we're storing a file, we're already storing a file of some kind, so we're just talking about what kind of file it is. I'm just talking about a different set of tradeoffs one can make if that file is something other than JSON.

Re: JSON Canvas – An open file format for infinite canvas data

#54

Post by gcr »

wongarsu wrote: post #49
gvx wrote: post #19

Earlier quoted context omitted.

Yeah, other details are missing too. For example backgroundStyle : > cover fills the entire width and height of the node. Does that work like the CSS background-size: cover; or background-size: 100% 100%; ? > ratio maintains the aspect ratio of the background image. Does that mean CSS cover ? contain ? Something else?

Colors can be specified in hex format, e.g. "#FFFFFF". Six preset colors exist, mapped to the following numbers: 1 red 2 orange 3 yellow 4 green 5 cyan 6 purple I'm sure everyone will infer the same color codes here. Maybe the file format isn't meant to reproduce the exact same look in different software, but merely communicate user intent. Your guess is as good as mine.

I’d almost prefer string literals for color with constants like “red”, “blue”, etc. that compatible implementations could theme as they see fit (eg terminal emulators). Perhaps that’s the intent behind the numeric constants but string literals would convey that better IMO

Re: JSON Canvas – An open file format for infinite canvas data

#55

Post by Macha »

Retr0id wrote: post #47
eropple wrote: post #36

Earlier quoted context omitted.

This is always a tough spot in JSON, I think. You want the `id` in the node or edge object, but you also want uniqueness. I don't think there's a great way to get this any be able to just `JSON.parse()` and go without further fixup.

What do you concretely gain from embedding the id within the object?

You have a reference to an object, maybe found by filtering the list based on co-ordinate intersection, and you need its ID to put somewhere else (e.g. in the "to" field of an edge). Sure, all your find/filter methods could return (ID, object) or just return an ID and make you do a second lookup to find the object, but at the kind of object counts we're talking about for this implementation, a small amount of extra memory to have the ID as a field in exchange for a nicer API is a reasonable tradeoff.

Re: JSON Canvas – An open file format for infinite canvas data

#56

Post by simonw »

jakelazaroff wrote: post #51
simonw wrote: post #31

It would be neat if the README or spec included links to some real-world examples of files - would be easier to start playing with building simple tools on top of this if there was already an example file to start experimenting with, without me having to learn Obsidian first. UPDATE: Figured out how to create one: 1. Install and then open Obsidian 2. Click the "Create new canvas" icon - third down of the icons on the…

If you hit "toggle output" on the bottom right, it shows a JSON Canvas representation of the page's content.

Is that an icon? I can't seem to find it (Obsidian 1.4.16 on macOS)

Re: JSON Canvas – An open file format for infinite canvas data

#57

Post by gcr »

iainmerrick wrote: post #16
jakelazaroff wrote: post #3

I 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…

It would be fun to go the postscript route and have the nodes be specified by some bytecode on some VM that lays the objects out on the canvas while specifying their editable properties.

Then, conforming implementations could render any document just by following the instructions, while editors that actually understand them can provide their own high-level control.

The trick is keeping it editable, which postscript doesn’t do well.

Example: if the language is strong enough to, say, implement force-directed node layout, an editor that doesn’t understand it could still add nodes and they would move around according to the document author’s wishes whereas perhaps the original editor might have more powerful editing capabilities.

Re: JSON Canvas – An open file format for infinite canvas data

#58

Post by desmondl »

Retr0id wrote: post #21

If ids are unique strings, then why are `nodes` and `edges` arrays, as opposed to id-string-keyed maps?

An object in JSON is meant to be unordered [1], so arrays are better if you want order to be preserved.

[1] https://www.json.org/json-en.html

Re: JSON Canvas – An open file format for infinite canvas data

#59

Post by jakelazaroff »

simonw wrote: post #56
jakelazaroff wrote: post #51

Earlier quoted context omitted.

If you hit "toggle output" on the bottom right, it shows a JSON Canvas representation of the page's content.

Is that an icon? I can't seem to find it (Obsidian 1.4.16 on macOS)

Sorry — I mean on the bottom right of https://jsoncanvas.org!

Re: JSON Canvas – An open file format for infinite canvas data

#60

Post by curtisblaine »

What I would expect from an infinite canvas app would be a streamable data structure, that can be rendere on demand on a "virtual" canvas - let's say you have a window from 0,0 to 100,100 - you can query the data structure to give you only the nodes in the viewport + the nodes connected to them.
Post reply on HN