[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: More vis(3) options
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.
Main Index |
Thread Index |