We do a number of string conversions in Mozilla: UCS2<->UTF8, URL encoding and decoding, uppercasing/lowercasing, search and replace, charset conversion, BIDI, and Arabic Shaping are a few. By consolidating the system for converters we can help achieve several important effects: ease of writing / understanding converters, efficiently chaining one converter to another to produce multiple conversions on a string, minimizing mallocs and string copies, and even using the same filters both for strings and input streams. Current converters fall into two categories, those that create a buffer and copy into it (sometimes twice, to avoid excessive memory usage), and those that append into a string. Both versions as their primary problem create extra intermediate copies of a string when you try to chain conversions together; and the former version requires one or two mallocs in all cases as well. I suggest the creation of an abstract converter interface that: - works with strings (nsAString in, nsAString out) - allows chaining one converter to another with a minimum of mallocing - makes it easy to implement a new conversion - has a simple syntax for use (hopefully something like FilterA(FilterB(FilterC(str))) would work) Being able to work with Input/OutputStreams might be nice as well. nsAStringGenerator does not allow chaining or streams but does (or can) solve all the other requirements. I have been working on one that does solve the other requirements.
I have a solution here which involves char filters, which can be chained together and which pretty much push the data down the line, changing it as they see fit, until it ends up in the destination string. jag has suggested adding a more pull-based mechanism (like an InputStream) and I am investigating. It needs some compiling before I want to post it. This bug is sort of a placeholder for it right now.
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla1.4beta
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.