search

naomijub / edn-rs

[DEPRECATED]: Crate to parse and emit EDN
https://crates.io/crates/edn-rs
MIT License
81 stars 14 forks source link

Collaborators wanted! #109

Closed evaporei closed 10 months ago

evaporei commented 1 year ago

@naomijub and I created this and edn-derive to be able to sanely send and receive structures to XTDB (previously know as CruxDB), thus giving birth to transistor.

However we both moved on to other projects and don't have time to invest in further development of these libraries. We're looking for new collaborators. Recently @Grinkers has doing some contributions, if you're interested we can give you access to the repo :slightly_smiling_face: .

Grinkers commented 1 year ago

Thanks for bringing this up. It was something I was thinking about too. I would be more than happy to help maintain, especially if I had both of your blessings for directions. I don't want this to come off as confrontational (I've come out of nowhere with lots of breaking changes); it's just different use-cases. I work mostly with real-time systems that need runtime/allocation guarantees, often tied to hardware.

List of thoughts and questions in no particular order or significance.

Project future

  1. What policy did you have in mind for PR vs straight contribution?
  2. Perhaps we should create an org? That way it's easier to add more people, do full hand offs, etc in the future. I think it would be useful to have more modern example projects in there. Such as clojure calling rust all compiled with graalvm. The current examples seem abandoned/archived/outdated. My dream example would be babashka scripting remote hardware with just edn data back and forth. https://docs.github.com/en/repositories/creating-and-managing-repositories/transferring-a-repository#whats-transferred-with-a-repository everything could be clearly transferred, including stars/history/etc.
  3. What about crates.io releases? Perhaps link it to a new org?

  4. It seems like edn-derive functionality could probably be merged into edn-rs?

    Things I personally would like

  5. a std only impl, features for other things. eg the discussion in #106 currently
  6. borrow impl as mentioned a little here: https://github.com/naomijub/edn-rs/issues/105#issuecomment-1714400848
  7. (long term) investigate no_std https://github.com/rust-embedded/heapless It likely would end up a subset of features (eg. no escape characters, sets, etc).
  8. At this time, no interest in maintaining transistor, but willing to help support the use-case. It seems like it has been archived anyway.
naomijub commented 1 year ago

I'll answer this week, I promise. But our vision was to just guarantee edn spec for our usage with crux/transistor. Since they transitioned to xtdb, we unsuccessfully tried binding it with RPCs (gXTDB). And many rust time serial databases were created after our prototype wooridb. So there was a lack of necessity to maintain this on our side.

Another usage was for brcode, a Brazilian e-transfer system. It had 3 clojure APIs using edn-rs to parse qrcodes. As far as I know, they are all replaced with pure clojure now

naomijub commented 1 year ago

Transistor will be archived. There were some efforts to port it to xtdb, but was too much effort for too little gain.

I liked the org idea. Name suggestions? Clojurs?

naomijub commented 1 year ago

What policy did you have in mind for PR vs straight contribution?

Perhaps we should create an org? That way it's easier to add more people, do full hand offs, etc in the future. I think it would be useful to have more modern example projects in there. Such as clojure calling rust all compiled with graalvm. The current examples seem abandoned/archived/outdated. My dream example would be babashka scripting remote hardware with just edn data back and forth. https://docs.github.com/en/repositories/creating-and-managing-repositories/transferring-a-repository#whats-transferred-with-a-repository everything could be clearly transferred, including stars/history/etc.

What about crates.io releases? Perhaps link it to a new org?

It seems like edn-derive functionality could probably be merged into edn-rs?

I'm Good with all issues you would like to see, I do have a suggestion for Hashing hashing hashmaps. I have used in another project consistant hashing for this, with the fx-hash crate.

Another thing people have asked is compatibility with serve as it's underlaying parser, but I don't think this si a requirement

Transistor has been achieved, so no worries there

naomijub commented 1 year ago

@evaporei what do you think?

Grinkers commented 1 year ago 
* I'm sad about the stars, because I like them, but I'm not against the idea, it makes a lot of sense to live inside an Org.

From https://docs.github.com/en/repositories/creating-and-managing-repositories/transferring-a-repository#whats-transferred-with-a-repository When you transfer a repository, its issues, pull requests, wiki, stars, and watchers are also transferred.

I've seen it successfully done, but have never personally done it. The nice thing is, as long as you don't create a new repo with the same name on your account, it'll even forward to the new org's repo (it'll essentially keep any links around the internet as valid too!). It might not be a bad idea to create the new org, figure out the permissions etc, create a new repo to do a dry run on. I feel history is very nice to preserve.

naomijub commented 1 year ago

One idea that occurred, is that we create a fork in the org and I achieve the previous one, while transferring the cargo credentials to the org. Plan B, maybe

evaporei commented 1 year ago

I like the org idea :slightly_smiling_face: , would it be edn-rs? I'm also not against having a monorepo with a crates folder. If we go this path, I can archive edn-derive.

Grinkers commented 1 year ago

I think a monorepo is good. I think the direction rust has taken, most people would would probably expect an optional feature derive, or the like, to add in additional features/dependencies.

Grinkers commented 11 months ago

I'd be happy to move https://github.com/Grinkers/edn-rs_fuzzer over to the org too. It could serve as a template for FFI for clojure (jvm). I think the current example leaks memory (c api, without a free), while has the JVM handle the freeing (it uses https://github.com/jni-rs/jni-rs)

evaporei commented 11 months ago

Perhaps we can create the org this weekend @naomijub ?

Also, I would really like to thank you @Grinkers for the amazing work you've been doing. If it wasn't for you, these crates would be abandoned, and Rust wouldn't have a decent way of using EDN :slightly_smiling_face:

naomijub commented 10 months ago

@evaporei might be good to fork and detach edn-derive as well

evaporei commented 10 months ago

I just transfered instead of forking edn-derive into the edn-rs organization.