From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@cse.psu.edu
From: ccsdhd@bath.ac.uk (Dennis Davis)
Message-ID: <1014038394.18195.0.nnrp-14.d4f0e306@news.demon.co.uk>
Subject: [9fans] Re: Inferno, filter.m
Date: Mon, 18 Feb 2002 13:48:37 +0000
Topicbox-Message-UUID: 5245dde4-eaca-11e9-9e20-41e7f4b1d025

bengt wrote:
> is it a good idea to follow the filter module interface when writing data 
> processing modules?
>
> i ask since neither dd, gettar, lstar, puttar, uuencode, uudecode etc seems to 
> do this.

the filter interface was an just an idea as to how one might structure
the API to a filter-like program without using pipes (which are
somewhat awkward to use when you're writing and reading from the same
program at the same time).

for compression, for example, it provides a reasonably lightweight way
to have several independent compressing streams without loading and
initialising a separate module for each.

the thread-based nature of the interface means that the filter can be
written in a natural (non-callback) style, and the channel-based
interface means that a few data copies are avoided.

in the end, i don't really know whether it was worth it, but if you
are considering writing a data-filter interface that you'd like to be
easily usable from Limbo code, you might consider it.  if not, it's
probably easier just to use a conventional stdin->stdout interface
using Bufio.

  cheers,
    rog.