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