The only encoder that makes a bit of noise to me is the ZnByteEncoder that contains a lot of mapping tables for mostly unused encodings (plus methods with metadata to recreate them)...
El vie., 5 de jun. de 2015 a la(s) 6:30 p. m., Sven Van Caekenberghe < s...@stfx.eu> escribió: > > > On 05 Jun 2015, at 18:20, stepharo <steph...@free.fr> wrote: > > > > Sven > > > > we were talking about splitting your package into two parts :) > > Would you be ok to get the basic encoders in a separate package? > > Zinc-Character-Encoding is already a separate package, it depends on > nothing. > Zinc-Resource-Meta is next up (containing URL and Mime-Type). > Both are completely independent of any HTTP stuff. > All this is by design. > > You probably mean that you want a separate config ? Right now they are > just a groups. > > > We were also thinking that NullEncoder could be called AsciiEncoder? > > Maybe, maybe not, let me think about that a bit. > > > Stef > > > >>> On 05 Jun 2015, at 18:09, Damien Cassou <damien.cas...@inria.fr> > wrote: > >>> > >>> > >>> Guillermo Polito <guillermopol...@gmail.com> writes: > >>> > >>>> Well, I made a cleaner implementation at the side with > >>>> > >>>> - a simple File object that is a sequential File as we all know > >>>> - a binary File stream on top of it that is composable with Zn > encoders and > >>>> other decorators > >>>> - a new interface to access Stdio streams > >>> that's really good news Guillermo. > >> Yes it is (need time to look at this in detail) > >> > >>> Is it ok to make File reading depend > >>> on Zinc? This sounds strange. Wouldn't that make bootstrapping harder? > >> It does not depend on the HTTP part, but on the Encoding part below it, > so that should be OK. > >> > >>> -- > >>> Damien Cassou > >>> http://damiencassou.seasidehosting.st > >>> > >>> "Success is the ability to go from one failure to another without > >>> losing enthusiasm." --Winston Churchill > >>> > >> > >> > > > > > > >
