Re: [9fans] dataflow programming from shell interpreter

[Eris Discordia <eris.discordia@gmail.com>]

> 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.

It didn't occur to me at all that anyone would want to implement DirectShow
or anything like that on Plan 9. Anyhow, I suppose if anyone's going to do
that they should probably first work on fast display drivers that leverage
modern cards' overlay capabilities and a facilitating media infrastructure
equivalent to DirectX. On run-of-the-mill PCs good video works depends a
lot on software support of video hardware, of course.

The logic inside most DirectShow filters either is open source (like
ffdshow) or has good open source equivalents. The interfacing (COM), as you
have noted, and input/output, which is hardware-dependent and therefore
probably weakly developed in Plan 9 (I don't really have an idea, just
guessing), are the missing bits from a DirectShow-like (multi-pipe) video
processing pipeline on Plan 9.


--On Thursday, January 21, 2010 13:36 -0800 Skip Tavakkolian
<9nut@9netics.com> wrote:

>> 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.
>
>