ideas VS jsonstreamingparser

State Encryption was one of those long requested features[0] (I had it on my ideas list for years[1]) that Hashicorp didn't have much incentive to build. I don't think it has to with distancing opentofu as such, but the opentofu team prioritizing the right things that customers actually need.

[0]: https://github.com/hashicorp/terraform/issues/9556

[1]: https://github.com/captn3m0/ideas#-mars-terraform-remote-htt...

What I would really like to see is “subscribeable OPML feeds”, so GitHub could provide a OPML feed for what shows up in your home page, and you any changes in your subscriptions (repos you watch etc) would change the OPML, which would then cause your feed reader to unsubscribe/subscribe to specific RAS feeds.

Unfortunately, this isn’t supported by the majority of RSS clients (tt-rss is the only one I know) which means in practice OPML feeds are merely import/export mechanisms.

Ref: https://github.com/captn3m0/ideas#opml-sync

I’ve been wanting to write a Mastodon/Twitter twine compiler that would take an existing Twine story and compile it to a list of posts.

https://github.com/captn3m0/ideas#twitter-adventure-maker

The primary difficulty is in flattening the state, which twine supports (apple=true, key=false in this story) but if it’s not too many variables might work out.

In my list of ideas is one for a Twine-compatible Twitter-Adventure Maker[0]. Remember those "choose your own adventure threads" that showed up on twitter and got viral a while back[1]. It would be great to be able to use Twine for authoring those.

[0]: https://github.com/captn3m0/ideas#twitter-adventure-maker

[1]: https://www.linkedin.com/pulse/media-trend-choose-your-own-a...

I wish OPML (the import/export RSS format) was also subscribe-able[1] in more clients. So my GitHub "news feed" would live at github.com/captn3m0/news.opml (which would just be a list of RSS URLs), and the client would update this list periodically.

Same thing works well for Twitter, or other sites.

[1]: https://github.com/captn3m0/ideas/#opml-sync

Almost exactly a fit against my idea[1] to generate OpenAPI from HAR files.

[1]: https://github.com/captn3m0/ideas#openapi-specification-gene...

Want to build the same, but using boardgame.io. Search for Gym here: https://github.com/captn3m0/ideas

I've been wanting something like this for an idea of mine[1]. Would love to have the ability to send arbitary responses (JPG/PNG)

[1]: https://github.com/captn3m0/ideas#svg-to-png-on-the-edge

Yes and no. You are correct about it being a document protocol, but it has long been set up as a big document protocol.

Most XML libraries are structured to receive XML in packets, in asynchronous bursts. I don't know of many JSON handlers that can do the same. They do exist (I use one, in the backend of one of my projects[0]), but they aren't as common. XML has packet/async built into OS SDKs, but JSON tends to be "The Whole Nine Yards" handling.

With Big Data/ML, I'm surprised that this is still a thing.

[0] https://github.com/salsify/jsonstreamingparser

In other languages, you generally wouldn't want to load super large JSON files all at once into memory as it uses a crapton of heap space, often creates far too many unnecessary objects, etc. Often you'd do a streaming parser of some kind, essentially discarding parts of the doc after you've processed them. For example (sorry for the dirty PHP link here, but it illustrates the concept): https://github.com/salsify/jsonstreamingparser/

There are few cases where such functions would be useful and could bring real impact. For example if you have to write custom JSON parser (and sometimes you have to - when working with large objects you simply could not have memory to store everything) you process strings often and byte by byte - then such improvements really could matter. And processing large json files is not uncommon task: https://github.com/salsify/jsonstreamingparser