Actually we just want to have a kind of split in: - essential - non-essential Then the bootstrap will include essential packages at the beginning and non-essential will be just loaded on top. The rationale is: the smaller the kernel, the fastest the bootstrap, and with it the feedback loop we have. That's why I was working on the File abstractions, and splitting some other kernel package. El vie., 5 de jun. de 2015 a la(s) 7:35 p. m., stepharo <stepharo@free.fr> escribió:
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 <guillermopolito@gmail.com> 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 < sven@stfx.eu> escribió:
On 05 Jun 2015, at 18:20, stepharo <stepharo@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.cassou@inria.fr> wrote:
Guillermo Polito <guillermopolito@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