[boost] Re: my 2 cents x 10 - Documentation, moreIO, iostreams, move_ptr, fsm, & boost

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2004-09-03 16:40:28

"Thomas Xkey" <xkey_at_[hidden]> 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_at_[hidden]> 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