shared wasabi implementation

[Fabrice Colin]

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.

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.

I hope this makes sense.

Fabrice