[gst-devel] (LONG) Extensive and unorthodox gstreamer use in app

[Lee Braiden]

Hi all,

Let me say straight off that I don't actually want to *implement* most
of what I'm discussing below.  I hope my project will be widely used
though, and think it's important to include a flexible structure for
handling different kinds of data.

I'm thinking of using gstreamer for my project, AMPU.  For those who
haven't heard of it, it's an online management system, initially
targeted at open source communities, as a way of organising themselves. 
The eventual goal is to create an open system of management for all
organisations, from local schools to entire governments.  The site is
here, if you need more info, although some of the details are a little
out of date:

   http://www.freesoftware.fsf.org/ampu/


Although the goals are a little different from usual groupware, AMPU
*is* basically a groupware system, focused on issue discussion, decision
making and voting.  The initial interface will be a GNOME UI, but I'm
aiming for UI abstraction, to allow web interfaces and things like that,
too.

Anyway, here are the relevant features I think AMPU needs (server side):


* Support for future dataformats, especially future opensource video
codecs, etc.

* Conversion of data formats, such as video->audio only, text->speech,
etc.

* (STRONG) Encryption support, for voting, etc.  I think a reasonable
way to do this might be with filters {en,de}crypting the data an
intermediate node in the pipeline, but I'm not sure on this.

* Support for many different character encodings, such as
ASCII->Unicode, etc.

* Automatic language translation (which I guess could probably be
implemented via a filter using something like babelfish).


With a GNOME user interface, I'd want to use gstreamer on the client
side too.  Essentially, the client will have a mimetype, or similar, for
a posted item, and will need to display that with an appropriate plugin,
whether it's just for viewing or for editing.

As I've said, I don't plan to implement all of this right now.  I expect
that document formats would initially be limited to simple ASCII XHTML
and JPEG/PNG images, with (possibly!) OGG audio, MPEG2 video, and
OpenOffice document formats as luxurious future extras.


Questions, then:

* How much of this is compatible with gstreamer's fundamental design
concepts?  Do I need to forget about gstreamer and look elsewhere?  I
think not, since my own diagrams for a system to implement this looked
quite similar to what's in gstreamer, but maybe I don't understand it
well enough -- I've only skimmed gstreamer's docs so far.

* Will gstreamer function OK within a daemon, without running o a GNOME
display?

* Does gstreamer have a simple way to say in a GNOME client to say,
"Build me a component for editing/viewing mimetype X, and display it in
container Y" ?

* Is it possible to add internal datatypes and filters to gstreamer
without polluting the wider gstreamer system?  Or perhaps it doesn't
matter, as long as I use typenames which don't conflict with other
things?

* Would it be possible to do things like keypair encryption using
gstreamer's filters?  I assume I would need to include the sender's key
in the incoming datastream, rather than pass it to the filter as some
extra parameter?  If so, would a filter have the necessary access to the
sink's (ie, the recipient's) keys?

* More generally, how do you all feel about this?  Does anyone find this
use of gstreamer inappropriate, or perhaps even offensive?  Would you be
interested in any patches I might have along these lines, or would you
prefer that I just adapt what code from gstreamer I need, add my own
modifications, and keep them away from gstreamer entirely?



Thanks for your patience :)

- Lee.