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

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

On Sat, Sep 18, 2010 at 02:00:24PM -0400, Thor Lancelot Simon wrote:
> On Sat, Sep 18, 2010 at 06:35:29PM +0200, Alistair Crooks wrote:
> > 
> > Yes, I was looking at making it an independent lib, so cksum,
> > uu(en|de)code, atob/btoa, asa can use it, as well as gaining new
> > functionality like command line and lib access to all kinds of
> > hashing, cksum, character set encoding and decoding, network name
> > resolution and reverse resolution, etc.
> 
> Do not forget vis/unvis (extra points for VIS_CSTYLE in both directions,
> tremendously useful for web work and would eliminate a highly irritating
> near-copy of strunvis() in the sh sources!) and the other compressors such
> as lzf.

Yes, vis/unvis is in there, along with URI %xx-style encoding and decoding.
 
> It would be amazingly cool to have a small framework to elegantly stack
> these via stdio.  The application does fwrite() but, under the covers,
> the data gets lzffed, base64 encoded, then spat out -- or the reverse.

Yes, that would be nice, but kind of orthogonal to libcodecs(3), I think.
 
> Though for that to not suck, there'd need to be some way to mux/demux,
> so things like hash values or crc32 could come back "on the side" of
> the main data stream.

I wonder if we could have multiple parents in a layer, or, alternatively,
think of it as a tee-style FILE on the side. So that the main data could
be sent through the normal layers, and a crc32 could be calculated as this
happened.

Still thinking about that last one -- thanks!

Best,
Alistair