From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <19fdeb6b36ad349c8856ef7330812e5e@9netics.com>
To: 9fans@9fans.net
Date: Thu, 21 Jan 2010 13:36:02 -0800
From: Skip Tavakkolian <9nut@9netics.com>
In-Reply-To: <FDED14C7429F34F377AEAA96@[192.168.1.2]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] dataflow programming from shell interpreter
Topicbox-Message-UUID: c21707d2-ead5-11e9-9d60-3106f5b1d025

> Aren't DirectShow filter graphs and programs like GraphStudio/GraphEdit one
> possible answer to the video processing question? Filter graphs can be
> generated by any program, GUI or CLI, and fed to DirectShow provided one
> learns the in and out of generating them.

DirectShow is COM; source/mux/transform/sink filters must provide a
number of interfaces (e.g.  IFileSinkFilter); other components
(e.g.  GraphBuilder) are there to make it easier to hook them
together.

i don't think a direct mapping of COM to Plan 9 fs model is
unnecessary.  for example, instead of mapping every control or
configuration interface and method to synthetic directories and files,
a single ctl file will do.  something like this seems sufficient:

	/ctl		# e.g. accepts run, stop, etc.  returns: paused, #outputs, config, etc.
	/event	# instead of callback notification
	/ipin/clone
	/ipin/n/ctl
	/ipin/n/event
	/ipin/n/data
	/opin/clone
	/opin/n/ctl
	/opin/n/event
	/opin/n/data

for a special purpose kernel one could add a driver and a fancy new
hook syscall (similar to pushssl and '#D') that would hook two fd's
together to eliminate the need for a user proc to transfer between
ipin/?/data and opin/?/data.