WIP: jsonMessages: basic schema for JSON APIs #6

Draft

ehmry wants to merge 1 commits from ehmry/syndicate-protocols:json into main

ehmry commented

2023-07-26 09:14:53 +00:00

Contributor

JSON APIs are ubiquitous. This schema allows for reusuable connectors that translate Preserves to and from JSON endpoints.

This schema contradicts the current JSON schema described in the Preserves spec because it uses symbols for object keys rather than strings.

JSON APIs are ubiquitous. This schema allows for reusuable connectors that translate Preserves to and from JSON endpoints. This schema contradicts the current JSON schema described in the Preserves spec because it uses symbols for object keys rather than strings.

ehmry changed title from ~~jsonMessages: basic schema for JSON APIs~~ to WIP: jsonMessages: basic schema for JSON APIs

2023-07-26 09:14:58 +00:00

ehmry commented

2023-07-26 09:15:47 +00:00

Author

Contributor

Marking WIP because I haven't been able to regenerate the bundle.

Marking **WIP** because I haven't been able to regenerate the bundle.

ehmry commented

2023-07-26 10:49:20 +00:00

Author

Contributor

Examples:

Examples: - Stdio: https://git.syndicate-lang.org/ehmry/syndicate_utils/src/branch/trunk/src/json_translator.nim - UNIX sockets: https://git.syndicate-lang.org/ehmry/syndicate_utils/src/branch/trunk/src/json_socket_translator.nim - websockets: https://git.syndicate-lang.org/ehmry/simplex_bot_actor/src/branch/trunk/src/simplex_bot_actor/websockets.nim

ehmry commented

2023-07-26 13:38:09 +00:00

Author

Contributor

I'm open to a more descriptive record for encapsulating messages, like <recv-json @data JSON>.

I'm open to a more descriptive record for encapsulating messages, like `<recv-json @data JSON>`.

ehmry force-pushed json from 4e5e5947b9 to 4a30cb442f

2023-07-26 16:21:01 +00:00

Compare

tonyg commented

2023-10-18 11:54:27 +00:00

Owner

I like the idea of including JSON as a schema in syndicate-protocols (or perhaps even with preserves schema itself??) but I'm not sure about using bool for JSON booleans and symbol for JSON map keys, since preserves (de)serialization won't actually read/write JSON for those cases unless I'm misunderstanding something. Can you explain a bit more about your reasoning?

I like the idea of including JSON as a schema in syndicate-protocols (or perhaps even with preserves schema itself??) but I'm not sure about using `bool` for JSON booleans and `symbol` for JSON map keys, since preserves (de)serialization won't actually read/write JSON for those cases unless I'm misunderstanding something. Can you explain a bit more about your reasoning?

ehmry commented

2023-10-19 16:51:24 +00:00

Author

Contributor

tl;dr It's just easier to write things that operate over dictionaries that always have symbol keys

I'm proposing two different schema for JSON, one you get when parsing the syntax of JSON to Preserves, and the other when translating the semantics of JSON to Preserves. Shifting the semantic translation as close possible to things that only speak JSON avoids confusion and mistakes later.

In practice I do stuff with programs that speak JSON over Websockets or UNIX sockets, and what I receive I parse as JSON and then translate to Preserves, and then send the Preserves as binary to the Syndicate server as a message (and vice-versa). I try to move as much of my logic as practical into the server's scripting language because that maximizes re-use, and not having to think about what is and what isn't JSON makes it easier to do that. Writing a deeply nested dictionary pattern and then using a symbol key where you need a string key is going to break things in a way that is hard to find.

Also I think it's too much work to write a code generator that can emit native types for dictionaries with symbol keys as well as string keys.

I was planning on writing a blog post on what I'm doing with JSON sockets in the next few days, and that should make my justification more clear.

**tl;dr It's just easier to write things that operate over dictionaries that always have symbol keys** I'm proposing two different schema for JSON, one you get when parsing the syntax of JSON to Preserves, and the other when translating the semantics of JSON to Preserves. Shifting the semantic translation as close possible to things that only speak JSON avoids confusion and mistakes later. In practice I do stuff with programs that speak JSON over Websockets or UNIX sockets, and what I receive I parse as JSON and then translate to Preserves, and then send the Preserves as binary to the Syndicate server as a message (and vice-versa). I try to move as much of my logic as practical into the server's scripting language because that maximizes re-use, and not having to think about what is and what isn't JSON makes it easier to do that. Writing a deeply nested dictionary pattern and then using a symbol key where you need a string key is going to break things in a way that is hard to find. Also I think it's too much work to write a code generator that can emit native types for dictionaries with symbol keys as well as string keys. I was planning on writing a blog post on what I'm doing with JSON sockets in the next few days, and that should make my justification more clear.

This pull request is marked as a work in progress.

This branch is out-of-date with the base branch

You can also view command line instructions.

Step 1:

From your project repository, check out a new branch and test the changes.

git checkout -b ehmry-json main

git pull json

Step 2:

Merge the changes and update on Forgejo.

git checkout main

git merge --no-ff ehmry-json

git push origin main

No reviewers

No Label

No Milestone

No project

No Assignees

2 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: syndicate-lang/syndicate-protocols#6

No description provided.