[9fans] Re: Inferno, filter.m

[9fans] Re: Inferno, filter.m

[Dennis Davis]

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.

[9fans] Re: Inferno, filter.m

[Dennis Davis]

In the referenced article, ccsdhd@bath.ac.uk (Dennis Davis) writes:
>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.

Sigh, a moderator mistake.  The above article was authored by:

From: rog@vitanuova.com

and *not* me...perhaps it was a mistake to get out of bed today...
-- 
Dennis Davis, BUCS, University of Bath, Bath, BA2 7AY, UK
D.H.Davis@bath.ac.uk