Roadmap for v1.0?

[cmyr]

quick-xml feels reasonably mature to me. Has there been any planning about a 1.0 release? Is there any major missing functionality that should be in place before this is considered?

[dralley]

Handling of encodings is the biggest missing piece (see my proposal at the end): #158

I was able to get that working in synchronous use cases but stalled out when working on async support, plus the patch set was so large it kept needing very painful refactors since the rest of the library was changing quickly at the time.

And then then I got sidetracked with contributions to a different project. So not much progress on it in the past ~8 months.

[cmyr]

oh heh I'd completely forgotten about that issue, and had sort of assumed it had been resolved.

Do you have a link to your WIP? If there's agreement on the approach I might be able to find some time to get it over the line...

[dralley]

#441

I just rebased it. I left some TODO comments but it's not complete. I will try to do another pass this weekend to see if anything easy can be polished off.

Listing briefly what I know isn't finished:

• There's a bug around encoding detection on the quick-xml side, because encoding_rs_io detects the encoding itself and then sends back UTF-8, so the former always detects UTF-8, and there's currently no communication for the latter to tell the former what the encoding was.
  • Also there's no way to make encoding_rs_io use a custom encoding detection scheme currently
• Async support
• If the encoding feature isn't turned on, we still ought to at least validate that the data being processed is UTF-8. That isn't done currently, only the encoding feature side is complete
• There might be a few unwrap()s left over in places where we eventually want to use str::from_utf8_unchecked() (unsafe, but if we already know the data is UTF-8 and that our boundaries are 1-byte characters, then we can use that safely)