* [9fans] Re: Inferno, filter.m
@ 2002-02-18 13:48 Dennis Davis
2002-02-18 14:31 ` Dennis Davis
0 siblings, 1 reply; 2+ messages in thread
From: Dennis Davis @ 2002-02-18 13:48 UTC (permalink / raw)
To: 9fans
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.
^ permalink raw reply [flat|nested] 2+ messages in thread
* [9fans] Re: Inferno, filter.m
2002-02-18 13:48 [9fans] Re: Inferno, filter.m Dennis Davis
@ 2002-02-18 14:31 ` Dennis Davis
0 siblings, 0 replies; 2+ messages in thread
From: Dennis Davis @ 2002-02-18 14:31 UTC (permalink / raw)
To: 9fans
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2002-02-18 14:31 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-02-18 13:48 [9fans] Re: Inferno, filter.m Dennis Davis
2002-02-18 14:31 ` Dennis Davis
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).