Re: More vis(3) options

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

On Sat, Jul 09, 2011 at 10:41:51AM -0700, John Nemeth wrote:
> On Nov 29,  6:50am, Emmanuel Dreyfus wrote:
> } 
> } I often have to recode a base64 encoder/decoder or a hexdump routine.
> } What about adding VIS_BASE64STYLE and VIS_HEXDUMPSTYLE to vis(3)? These
> } two could even be reversed by unvis(3)
> 
>     This sounds like the perfect use for that "string codec" thing agc@
> was talking about a while ago.  Did that ever get committed?

You're right, the codecs stuff was meant for exactly this.  I didn't
think codecs sat well within the vis/unvis structure, mainly because
of the integer constant used to specify the transformation, which I
think was not scalable for what I wanted to do.  Anyone familiar with
the python codecs should recognise the approach, too.

Other people had trouble with the way I implemented the codecs stuff -
in particular, some had trouble with using regular expressions to find
the correct translation to use, some with non-existent exit calls, and
others with the ways I used to cut down the number of translations
that were loaded.

In the end, I gave up - my intransigence to deal with it after 5
different proposals equalled the intransigence of the people who
didn't want it, and so I dropped the proposal.  In hindsight, the
timing was wrong for me, personally, too.

In passing, I still feel that if someone proposes openssl as the
solution for anything, the pre-requisites that that brings in render
the solution too obscure to be realistic.  If openssl were layered
better/at all, then things would be different.

Regards,
Alistair