shared wasabi implementation

[Magnus Bergman]

On Fri, 23 Feb 2007 21:26:26 +0800
"Fabrice Colin" <fabrice.colin at gmail.com> wrote:

> On 2/23/07, Magnus Bergman <magnus.bergman at observer.net> wrote:
> > What gstreamer does is to set up a pipeline for handling media
> > streams in a very generic way. The pipeline consists of a source
> > element, any number of filter elements and a sink element (which
> > could be an indexer of a document viewer). There are currently no
> > filter elements for handling text (except for subtitles and such).
> > But filters for converting, let's say word documents to plain text,
> > could very well be implemented as gstreamer elements. The benefit
> > from this is that the documents are streamed instead of first
> > downloaded (if necessary) and then converted (all in-process),
> > which is of course much faster. And gstreamer can automatically
> > figure out which elements are needed and set up an appropriate
> > pipeline for doing the job.
> >
> OK, I see. I agree that streaming documents is a better approach.
> 
> Most, if not all, third-party libraries to access and manipulate the
> document types I am interested in don't allow for document streaming.
> Basically, if I adopted a stream-based approach, I wouldn't be able
> to make use of the wealth of code that's been written, tested,
> debugged and optimized by others, and writing filters would be a much
> more difficult task.

That's true, but not a problem as I see it. Both approaches could be
used in parallel. A gstreamer based pipeline could be used as a stand
alone filter. And an element for gstreamer wrapping stand alone filters
could also easily be written (there might even already be one packaged
with gstreamer).

> Jos tried to get me to adopt the document streaming code he wrote for
> Strigi. I declined for the same reason. The time I would spend
> writing low-level document decoders is better spent elsewhere.

My point was not so much to prefer streaming over stand alone filters.
But rather to prefer gstreamer over some other streaming framework.
Since we already have gstreamer which is relatively robust and well
tested it would be a waste to add another streaming framework as well.