shared wasabi implementation

[Mikkel Kamstrup Erlandsen]

2007/2/23, Magnus Bergman <magnus.bergman at observer.net>:
>
> 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.



Forgive me being naiive - but I've always just related gstreamer to audio
and video streams, never with documents streaming on a more abstract level.

Can you give some examples on how you've used gstreamer in non audio/video
cases?

Cheers,
Mikkel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20070224/383b3e54/attachment.htm