"Thomas Xkey" <xkey@yahoo.com> wrote:
Review Periods
I would prefer to see a review period of 10-12 days [i like 12 days from a sunday thru the following weeks friday perspective.] The present period is just to short.
Agreed.
----------------------
Documentation !!!
Please utilize & include more diagrams & examples in your library documentation!!!!
Didn't you see http://tinyurl.com/7ylep, http://tinyurl.com/3pjps and http://tinyurl.com/3lvdw?
Compare & contrast with existing implementations that are lacking, State why they are lacking, what they are lacking, with what the proposed library implementation presents to fill the missing pieces, how it is better in some respects to anything it "replaces", and why it replaces some typical
library code currently in widespread use or fills a gaping hole.
I thought it might be interesting to add comparisions with java.io, Crypto++, OpenSLL and the Apache 2.0 filtering framework. But I didn't view this as essential, and just didn't have time.
moreIO & IOstreams
I think if you perhaps had looked into the other IO lib that jason was developing at the time you 2
Do you mean 'Jonathan' here?
coudl have had a meeting of the minds and come up with some great ideas and both done some things differently.
I posted at least four versions of my library, while I was developing it, and received a lot of good criticism. Daryle posted many versions of his library too. I examined Daryles, and I asked him to look at mine. What more do you want?
This library is a software community and with scales ever growing great ideas shouldnt necessarily be pondered on by lone rocket scientists squirreled away with their code and not picking their heads up to look around and talk
See above. I snipped the part of your message about your being a 'pita' but I'm considering adding it back. ;-)
Perhaps you 2 should get together and collaborate. [now there's a concept]
I suggested to Darlye that we combine our submissions, but he was not receptive.
This is why i would much prefer with some efficiency clean-ups & improvements that the turkanis library be used as a basis(implementation-wise) for any of the moreIO features accepted.
Specifics, please.
I like the small raw nature & flexibility of the simpler "building pieces" at the bottom of this IO pyramid I can then compose my complex streams on these "sinks & sources"
Thanks.
As to the turkanis library, I have not had as much time to examine it. I am not sure the merit of Carlo Woods remarks but from a 1st perusing I think i agree with him.
I have not posted my full response to Carlo yet, but I have tentatively concluded that the types of optimizations he is converned about (and the similar concerns of the architects of the Apache 2.0 filtering framework) are only required in limited cases -- roughly, when implementing network proticols or writing web servers. Most of the filters included with the library, and those suggested by reviers, would not benefit much, if at all. In some cases, it could slow things down. In addition, I've concluded that this functionality can be implemented later as an extension to the library, if desired, without modifying the current filter and resource concepts. 'Message aware' filter and resource concepts can be introduced and the internal filtering infrastructure can be reimplemented without modifying the public interface. It might be part of a 'networking library'. Finally, I have mentioned twice a number of optimizations I have not yet applied, because I don't know if they're necessary. (They should have been in the docs.) I'll paste them here again: Jonathan wrote:
There are several optimizations which I have held in reserve which would also minimize copying: a) Allowing resources to advertise that they are streambuf-based, so that i/o is performed directly to the underlying streambuf, with no additional layer of buffering b) Giving special treatment to symmetric filters (used to implement compression/decompression) to allow them to have direct access to the buffers of adjacent streambufs in a chain. c) allowing for a category of 'transparent filters' which simply observe character sequences, forwarding them unchanged. This would allow many useful filters (such as the offsetbuf suggested by David Abrahams) to have essentially zero overhead.
The category of transparent filters could be generalized any filter which can be repesented as a function
char f(char);
so that the length of a sequence of characters is never changed by the filters.
"Thomas Xkey" <xkey@yahoo.com> wrote:
I also partly agree with Daryl about some efficiency concerns and bloat concerns but i think with everyones assistance those can be hammered out or down in size.
Could you repeat Daryle's concerns which you found convincing? I asked him for clarification but I don't think he answered yet. Regards, Jonathan