Here is a first step in making the Zinc character encoding package lighter:
=== Name: Zinc-Character-Encoding-Core-SvenVanCaekenberghe.38 Author: SvenVanCaekenberghe Time: 9 June 2015, 5:21:51.278641 pm UUID: 8b4b6a04-d2a2-4fec-97fe-6faf498bc54b Ancestors: Zinc-Character-Encoding-Core-SvenVanCaekenberghe.37 Experimental change: introduction of ZnSimplifiedByteEncoder as a low memory variant of the full featured ZnByteEncoder, supporting only latin1 (iso-8859-1) and ascii. Move ASCII handling from ZnNullEncoder to ZnSimplifiedByteEncoder making it strict by default. Needs ZnSimplifiedByteEncoder initialize. ZnByteEncoder initialize. === Of course, now we have to decide how to really split the package, which parts to keep in the low level version, and which to move to the extended version. The tests might need splitting too. Sven > On 05 Jun 2015, at 19:35, stepharo <[email protected]> wrote: > > Yes sven but with guille we are working on a really small kernel. So we can > duplicate just the classes we need but I would prefer not > but we can do it. The size is important for us because it takes time to > bootstrap. > > Stef > > Le 5/6/15 19:06, Sven Van Caekenberghe a écrit : >>> On 05 Jun 2015, at 18:43, Guillermo Polito <[email protected]> >>> wrote: >>> >>> 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 >> 67 encoding specifications, each a 128 array. The method constant is shared >> when used. >> In the beginning there were only a couple, one day I added many more, some >> people need them. >> For me, the cost is reasonable. >> >>> (plus methods with metadata to recreate them)... >> That is just two method (which is pretty cool, I love spec based >> programming). >> >>> El vie., 5 de jun. de 2015 a la(s) 6:30 p. m., Sven Van Caekenberghe >>> <[email protected]> escribió: >>> >>>> On 05 Jun 2015, at 18:20, stepharo <[email protected]> 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 <[email protected]> wrote: >>>>>> >>>>>> >>>>>> Guillermo Polito <[email protected]> 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 >>>>>> >>>>> >>>> >>> >> >> > >
