I am writing to this list because it is the closest fit i am aware of. please be so kind to direct me to the right forums, MLs, etc. to expose and discuss&nbsp; this idea to/with the right people.<br><div class="gmail_quote"><br>
when thinking about the diverse, uncoordinated and code-duplicating mess that are all the different encoding/compression/processing libraries and programs out there i found the need to for a solution that brings order to the chaos once and for all.<br>


one that goes further than what gstreamers scope currently seems to be and possibly extends the way we think about operating system services.<br><br>it seems the following use cases have enough in common to be handled through a unified, system-wide api. please correct me if i am wrong.<br>
<br>
(ordered by decreasing existing use of gstreamer)<br>
1) a media file should be viewed on the screen<br><br>2)<br>a media stream should be captured to a file<br><br>3)<br>a 7-zip/LZMA archive should be created from a bunch of file handles<br><br>4)<br>a file system needs to handle transparent compression and/or encryption of inodes/whatever low level objects it uses<br>


<br>5)<br>a hash needs to be generated from a file stored on a different server, accessed through name-your-favourite-esoteric-protocol-here<br><br>6)<br>SETI-at-home needs to crunch some data using its FastFourierTransform Algorithm to find our future alien overlords and the user has a custom DSP specifically designed to speed up this process. using that would be easy - if he could just install the right FFT plugin<br>


<br>7)<br>a user of Photoshop, nay Gimp/Krita would like to utilize the SVG filter the Webkit implementation uses and dynamically stream that picture as a change-as-you-work-stream to a guy on the other end of the world who does some video processing with it<br>


<br>8) Complex:<br>high level objects work the same way - downloading and installing an rpm: <br><br>since many file mirrors(the respectable anyway) publish a hash alongside the file a la<br><br>SomeFile.rpm<br>SomeFile.MD5<br>

<br>handing the http or ftp location and the &quot;install&quot; command to the respective http source and rpm sinks(or both to an handle-archive--bin ?), the autoplugger could even go so far as to auto-insert potentially installed -gnutella/bittorrent/whatever,<br>

-hashing,<br>-SSL/TLS,<br>-security handling,<br>-decompression,<br>-caching<br>-db management<br>-and optional ask-the-user-for-input plugins into the pipeline to bring transparent P2P swarming to even the simplest of downloading applications.<br>

(the http source could dynamically create a a-hash-is-available-pad to facilitate that or the bin instantiates another connection. failing that it instantiates a plugin listening for user/system-input hashes. probably such a plugin should be preloaded by default and maybe create a dbus service for runtime/pre-run configuration of pipelines)<br>

<br>-----------------------------------------------<br><br>all these things involve some from of somewhat more complex algorithm being run on a buffer of data, be that either a static one of known type, or changing over time, necessitating renegotiation of the processing chain.<br>
<br>
automatic threading, scheduling, detection/plugging services and a generic interface to processing data would benefit the programming ecosystem greatly, imho<br><br>-----------------------------------------------<br><br>
benefits of one globally used stream processing api:<br>
- greatly reduced development effort, rate of bugs and maintenance<br><br>- reduced learning curve when adding functionality to software, furthermore a more structured way of thinking about processing data is also bound to produce cleaner code<br>

<br>- systems theory: standardizing components interfaces&nbsp; tends to lead to the discovery of novel ways to combine those, leading to innovative applications<br><br>- improve the functionality of existing applications simply installing a new plugin(to a certain degree)<br>

<br>- users decide which implementation they want to use, all in all, it&#39;s his/her decision to make.<br>the ability to stop having to install multitudes of http/etc protocol, VirtualFileSystems(KIO-slaves,GIO, PHP5&#39;s stream API ...), encoding(OpenSSL/GnuTLS/PGP ...), compression etc implementations just because the respective application developers had their favourites, would be a great step forward in the fight for truly free software and putting the user back in control of his own system.<br>

<br>- by moving up one abstraction layer, just one wrapper to support other programming languages is required-in contrast to per library wrappers<br>.<br>this last point essentially realizes most of the promise of .NET but in a somewhat less invasive fashion.<br>

many of the different installed (class) library implementations(from .Net to Z Machine) of similar functions could be unified into one, mostly user chosen set of plugins <br><br>---------------------------------------<br>

<br>speaking from a system architect&#39;s view,<br><br>i would like to move most if not all of the data&lt;-&gt;data processing of the Controller part of MVC into a high(er) level, unified and generic interface.<br><br>
only the [knowledge&lt;-&gt;]information&lt;-&gt;data parts (most of the &quot;business logic&quot;) should remain in the main application, as they are much more task specific<br>
<br>this should create a comprehensive view of the complex processing algorithms available(a part of the system services view, that could be advertised over a network vie e.g. ZeroConf) on a system and the partial automation should make customized deployment and management a lot better.<br>

<br>the plugin-&gt;library separation could still be kept in selected cases to allow for ultra-low-level operation and alternative stream processing apis, although for this class of algorithms it might be overkill.<br><br>
-----------------------------------------<br>
<br>Q: where do we stand with GStreamer in terms of being able to be the root of that api ?<br>- is it sufficiently generic ?<br>- is it simple enough ?<br>- is the core sufficiently light-weight and modular ?<br>- are plugins sufficiently simple&nbsp; to write and do they only add a negligible overhead by default ?<br>

- is the type-system powerful enough or can it be made to be ?<br><br>Q:Should gstreamer be split into a generic stream processing/plugin mgmt layer and a multimedia handling api layer for this ?<br>everybody should use the lower layer, and be competing on the higher API level(xine,mplayer,directshow ... not sure if phonon is in the same level)<br>

<br>Q: should the core go into the linux kernel to be universally available and be able to serve the kernel&#39;s needs(hashing, TCP/IP layer, crypto, VFS etc...) ?<br>can it even go there with the plugins staying in userland ?<br>

<br>Q: are the identification algorithms used for autoplugging also plugins so that they can be arranged into a pipeline that produces typeinfo?<br><br>it should be possible to load the data recognition/autoplugging parts separately since low level users don&#39;t want the extra overhead(e.g the CRC on an inode in a linux filesystem) <br>

<br>also, some users might prefer a unique autoplugging strategy on theirs systems<br><br>Q: what has to be done to make this vision a reality ?<br>who to talk to to hammer out a strategy ?<br>what skills/efforts are needed to implement it ?<br>

where to evangelize it ?<br><br>Q: since much work on gstreamer is sponsored by a specific company, what is their take on this ?<br><br>Q: and most important of all: does all that even make sense ?<br><br>thanks for reading and looking forward to your feedback and pointers.<br>

<br><br>best regards<br><br>MaxxCorp <br><font color="#888888"><br><br>-- <br>MaxxCorp Knowledge Management Solutions GmbH<br>Berlin - GuangZhou<br>Maxim Mueller - Founder and Managing Partner<br>
GZ Cell:13416104615<br>EMail: <a href="mailto:maxim_m@gmx.net" target="_blank">maxim_m@gmx.net</a><br>
</font></div><br>