RFC: Deprecate in favor of zlink?

[zeenix]

@haraldh @cgwalters I just rolled out the first zlink release. I already provide all the features of this crate I believe and some more (e.g pipelining) and provides an async API (with blocking wrappers in the plans). Given that I now would have no motivation to work on this project and seems you folks don't have the time and/or motivation to maintain this either, I suggest deprecating this project in favour of zlink. WDYT?

[haraldh]

So, instead of adding it here, you decided to roll your own? Why? Was it important to have the "z"? Anyway, thanks for creating it! MIT License is great also.

[zeenix]

So, instead of adding it here, you decided to roll your own? Why?

Because this repo is a mess tbh. It's hard to even know what was released and what wasn't (tags are missing etc). I had originally planned to merge it all here once it's ready but I just didn't have the motivation to go through the work. It's much easier to just create a separate thing from scratch.

Also while I was working on the project for several months, I shared the project with others and the name got a bit famous, so there is a bit of that as well.

Was it important to have the "z"?

Not really. 😆

[LevitatingBusinessMan]

I am not sure if zlink fits my use-case. The ideals of varlink are to be as simple as possible.

Varlink aims to be as simple as possible. It is not specifically optimized for anything else but ease-of-use and maintainability.

Compare zlinks documentation with this crate. Why is zlink so complicated?

I don't need/want an async api. I just want to create a varlink service and client with the least amount of code possible.

So although I highly appreciate your work, I personally would opt for a simpler library.

[zeenix]

So although I highly appreciate your work, I personally would opt for a simpler library.

Then write a library with the approach/API you like.

[LevitatingBusinessMan]

So although I highly appreciate your work, I personally would opt for a simpler library.

Then write a library with the approach/API you like.

Well I like the approach of this crate. This issue is an RFC to discuss the topic of deprecation in favor of zlink right?

[zeenix]

So although I highly appreciate your work, I personally would opt for a simpler library.

Then write a library with the approach/API you like.

Well I like the approach of this crate.

But it's unmaintained. You can fork it if you like.

This issue is an RFC to discuss the topic of deprecation in favor of zlink right?

Yeah, because most people want an async API and a library that's maintained. If you fork this crate and demonstrate that you'll be maintaining it, I would be more than happy if we point to your fork along with zlink.

[LevitatingBusinessMan]

Why would you prefer deprecating the whole project to point to a fork? I would personally be looking for new maintainers. But like you said in #123 I guess that's kind of out of your hands.

I will look into forking the project and then drafting the proper releases for rust 2024. If that works out, we can discuss with @haraldh if we want to continue development here.

I noticed you're also the maintainer of zbus btw. Will you present again at FOSDEM this year?