From: lm@mcvoy.com (Larry McVoy)
Subject: [TUHS] the sin of buffering [offshoot of excise process from a pipeline]
Date: Wed, 16 Jul 2014 08:41:53 -0700 [thread overview]
Message-ID: <20140716154153.GC31888@mcvoy.com> (raw)
In-Reply-To: <CAEoi9W6Baw6fpc8uwPzXNiP3xSSmC8FvPF2mouaVngbvoJHFiw@mail.gmail.com>
What is being provided is a generic layering system on top of stdio.
Any sort of conversion you want. Encryption, CRC, XOR block, compression
(we support gzip and lz4). Those are just the layers we use right now,
it's easy to imagine others being added.
The point is that there is no one API that is going to pleasantly encode
all of the options to all of those layers and any that may come later.
Are you seriously suggesting that you want to read the freopen(3)
man page and see all of these options explained? That's the classic
open source way, dump everything in one poorly thought out man page.
It's not the Unix way, people think about it harder.
For the record, I pushed for the single string encoding as well but got
pushed off it as I realized the API wasn't as simple as I imagined.
While you could do it that way you shouldn't do it that way, it's just
not a good API.
I'm very pleased with how it turned out in our code, other than a handful
of fpush() calls, it just looks like stock stdio.
On Wed, Jul 16, 2014 at 10:56:57AM -0400, Dan Cross wrote:
> Why can't those be embedded in the relevant string? freopen(fp, "rx{128}")
> or something?
>
>
> On Wed, Jul 16, 2014 at 10:30 AM, Larry McVoy <lm at mcvoy.com> wrote:
>
> > On Wed, Jul 16, 2014 at 02:03:58AM -0400, John Cowan wrote:
> > > Larry McVoy scripsit:
> > >
> > > > We tried that but the problem is that you can't encode all the options
> > you
> > > > want in just a character. Compression doesn't take options, the
> > CRC/XOR
> > > > layer wants to know how big you might think the file is (because we
> > > > support blocksizes from about 256B to 256K and we want to know the
> > > > file size to guess the block size).
> > >
> > > It's a string: you can have as many characters as you want.
> >
> > I understand your desire to have one API. We tried and it just wasn't
> > practical. Imagine pushing an encryption layer that wants a key,
> > XOR layer that wants block size, etc.
> > _______________________________________________
> > TUHS mailing list
> > TUHS at minnie.tuhs.org
> > https://minnie.tuhs.org/mailman/listinfo/tuhs
> >
--
---
Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
next prev parent reply other threads:[~2014-07-16 15:41 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-15 23:43 Doug McIlroy
2014-07-16 0:32 ` Larry McVoy
2014-07-16 3:53 ` John Cowan
2014-07-16 4:05 ` Larry McVoy
2014-07-16 6:03 ` John Cowan
2014-07-16 14:30 ` Larry McVoy
2014-07-16 14:56 ` Dan Cross
2014-07-16 15:41 ` Larry McVoy [this message]
-- strict thread matches above, loose matches on Subject: below --
2014-07-16 21:46 Noel Chiappa
2014-07-15 2:31 Doug McIlroy
2014-07-15 2:40 ` Larry McVoy
2014-07-15 18:55 ` scj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140716154153.GC31888@mcvoy.com \
--to=lm@mcvoy.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).