Potential API changes in http_sfv (dependency)

[mnot]

Hi,

I'm looking at changes to http_sfv, and noticed that this library depends upon it.

See a summary of how it would work. Basically, it's moving from an object-based approach to a set of functions that produce datastructures. This should be more performant and I think more straightforward to use.

I'm writing here to ask:

1. If you have any thoughts / preferences about the API.
2. If the new API is merged, how you'd like to manage the dependency. I'd probably version it as 0.10.1, FWIW.

[kislyuk]

Hi - this seems fine, I don't have any strong preferences one way or another. I have a vague idea that an object-oriented API might make it easier to type hint the interfaces appropriately, but I'm not sure if that's a good reason to stay with that approach.

To manage the dependency, I imagine I'd start by publishing a release to this package to depend on http-sfv >= 0.9.8, < 0.10. Then once you publish your update I will do a release that updates the API and depends on http-sfv >= 0.10.1. Does that sound right? If so, I can push an update in the next day or two.

[kislyuk]

Also, thanks for publishing http-sfv. It's a really useful package and important building block that has been reliable and predictable.

[kislyuk]

Hi @mnot,

After several unsuccessful attempts to migrate from http-sfv to http-sf, I have decided to stick with http-sfv. I think its API suits the needs of this library better.

If you prefer not to maintain that package, I can make a copy and vendor it in a subdirectory in this package. Thanks again for all your work on this.

[mnot]

Thanks for trying. Was there something fundamental about it that made it unworkable, or is it just the object vs. functional API?

It should be possible to add an optional object interface to http-sf, if that would be helpful.