Is considered this a "need to have" or "nice to have" feature?
Since it's gone so long without getting much attention and it introduces other feature regressions, it sounds like it is more a "nice to have" feature.
But if it is classified as a "need to have" feature ... then it would make sense to allocate resources to fix it and sort out these issues.
The challenge is of course the available time to look into fixing this. And if it is just classified as a "nice to have", then I'd say kick it out now and rather prepare a clean ground for another attempt later on if this resurfaces as something really needed.
IMHO, carrying dead code promising to improve memory safeness does not deliver any of the expectations and it doesn't help anyone at all.
it is unclear if it is needed. I could be considered part of the rust camp, but I would generally use hyper directly, not through curl. If I wanted or needed to use curl, it seems unlikely that hyper support would affect my decision making process.
they hyper maintainer was just on rustacean station podcast and mentioned this effort. Sounds like they personally won’t get involved but they are doing the full-time open source maintainer thing.
@Schneems I know that. Sean and the team work hard on hyper itself. That's not the issue. The problem is that nobody seems to actually want hyper in libcurl bad enough and work on making it real. So it just becomes a burden.
@Schneems There's a few players in the ecosystem now that fund maintainership. If y'all are interested, maybe we can see if we find someone? I just have zero idea what amount of constant effort that would be.
I think it is worth for #hyper and the #rust ecosystem to work as #curl backend but not other way around. The only reason for curl to support hyper is to validate that the backend api is flexible enough and to have another "validator" for such interface. But probably it is one of those piece of code that maintainers are happy to push to third parties 😅
I am (and have been) working on fixing the lack of http/1.1 trailers support.
I was going to move on to any other issues with curl. I was also going to start providing some builds of curl that use the hyper backend for linux and macos so people could use it.
Stefan Eissing
in reply to daniel:// stenberg:// • • •🔗 David Sommerseth
in reply to daniel:// stenberg:// • • •Is considered this a "need to have" or "nice to have" feature?
Since it's gone so long without getting much attention and it introduces other feature regressions, it sounds like it is more a "nice to have" feature.
But if it is classified as a "need to have" feature ... then it would make sense to allocate resources to fix it and sort out these issues.
The challenge is of course the available time to look into fixing this. And if it is just classified as a "nice to have", then I'd say kick it out now and rather prepare a clean ground for another attempt later on if this resurfaces as something really needed.
IMHO, carrying dead code promising to improve memory safeness does not deliver any of the expectations and it doesn't help anyone at all.
daniel:// stenberg://
in reply to 🔗 David Sommerseth • • •@dazo yes, that's basically the question. But it is not an objective fact. It depends on your viewpoint.
The people in the "everything must be done in rust" camp would probably say it is a need. But they don't seem to show up to help with the work.
So here we are, me asking the question...
gigantos
in reply to daniel:// stenberg:// • • •Richard Schneeman
in reply to daniel:// stenberg:// • • •daniel:// stenberg://
in reply to Richard Schneeman • • •Florian Gilcher
in reply to daniel:// stenberg:// • • •gianarb
in reply to daniel:// stenberg:// • • •Herman J. Radtke III
in reply to daniel:// stenberg:// • • •I am (and have been) working on fixing the lack of http/1.1 trailers support.
I was going to move on to any other issues with curl. I was also going to start providing some builds of curl that use the hyper backend for linux and macos so people could use it.