Re: Proposed addition of strcodecs(3) library - review requested

[Alistair Crooks <agc%pkgsrc.org@localhost>]

On Sat, Sep 18, 2010 at 01:23:13PM -0400, Thor Lancelot Simon wrote:
> Another very general comment: Christos suggested to me long ago that
> the right way to deal with the profusion of things like this in our
> tree was to hook the underlying transform functions up to stdio via
> funopen().  This is a little easier and more general now because the
> current XPG draft includes Linux' fmemopen().
> 
> In general -- and I'm not saying "redo your work, the abstraction is bad",
> I'm asking you your opinion since you've actually done the work to build
> an abstraction around this once, and I haven't! -- what do you think of
> that idea?

I took some time to think about this one, so sorry for not getting
back to you straight away.

I like this idea a lot -- it's something I've wanted for a while, but
has been back burner.  The stdio abstraction is in most of the
programs we have, although it is being replaced in some places with
mmapped input, particularly for speed.  Being able to fprintf into a
string would be great. Being able to layer input would be even more
effective, since then we would just be able to hook up individual
layers of FILE *, and we could have buffered input for free from a
compressed libarchive file, to name but two.

But I still think that I would like to pursue libcodecs(3) -- as it
has been renamed -- and use that as yet another layer of input to a
layered stdio.  I don't see its abstraction as being bad - just
implementing another (fairly low layer).

Many thanks for the feedback -- real food for thought.

Best,
Alistair