-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/04/2015 04:54 PM, Henri Sivonen wrote: > On Fri, Dec 4, 2015 at 3:18 PM, Ted Mielczarek <t...@mielczarek.org> > wrote: >> 1) What does Servo do, just use rust-encoding directly? > > That is my understanding, but it would be good if a Servo > developer could confirm.
This is correct. >> 2) Instead of a clean-room implementation, would it be possible >> to fix the problems you see with rust-encoding so that it's >> suitable for our use? Especially if Servo is already using it, it >> would be a shame to wind up with two separate implementations. > > I'm shy to suggest to the rust-encoding maintainer that I should > be able to come in and trample all over the rust-encoding > internals because of Gecko and what I see as priorities from the > Gecko-informed point of view. It doesn't make sense to implement a > Gecko-ish API where the caller allocates the output buffer (like > I'm proposing) on top of rust-encoding. However, it would make > sense to implement (at least the common call patterns of) the > rust-encoding API on top of the kind of API that I'm proposing. But > in order to do so, the internals of rust-encoding would end up > replaced with the kind of library that I'm proposing. > > As for whether any parts of the rust-encoding internals would be > reusable in the kind of library that I'm proposing, as noted in > the proposal document, it generally makes no sense to adapt one > implementation strategy for the single-byte encodings to another. > If you want a different implementation strategy for the > single-byte encodings, it simpler to just rewrite from scratch to > the strategy that you want. > > As for the multi-byte converters, the concern I have is that > rust-encoding implements them using a macro that generates a state > machine and this makes the code look different from the algorithms > from the spec. It might be really dumb of me to suggest not using > that macro, but I think there is value to having the code look like > the algorithms in the spec so that it's easy to compare the two. So > in the case of multi-byte converters it's mainly a question of > whether we prefer the (possible really cool) macro or code that is > easy to compare with the spec. I currently prefer code looking like > the spec, but maybe I could be convinced otherwise. (Either way, > I'd get rid of the encode-optimized lookup tables and search the > decode tables in reverse instead.) > > It would probably be worthwhile to copy and paste from the > rust-encoding UTF-8 and UTF-16 converters. I agree that it is useful to have code looking like the spec in the general case. However, if we were to get to the point where that was the only argument against unifying your proposed library and rust-unicode, I think we should probably go for the unification anyway. HTH Ms2ger -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJWYblSAAoJEOXgvIL+s8n2uwQH/ipxhkqZpqZIEZIZcAezbKfw 1on3mC/0cnwJywu9yqqlTSXAoQJxONbdWeLJnRU9RvEgreT+EOp+0ktRgUubg34h qAew1zdRhS7ldIZTWyePX4EOpUsvtIqXXpyJcw3Tl76bTx+skp3mov+lhZxTLS/3 ZsDayhHuYwhSB/h2KfYP09ee5i3AyKPjWkPyWIMw9jRXxJD+bWVcj++V1s2/3V9R A4MnAJOB8Cqyhp+aMi1+mbx2QTYEqXqLak9ifKV0hHfF80+qI3aGkFQhr/fbhdgl 9rSBz7gI4lVzXtt8wSNaBGnRSf5mGvGmz5wQC7VyGtj2NMYKcmbCErXavhiSW6g= =ixRO -----END PGP SIGNATURE----- _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
