[gst-devel] gstreamer manual split up

[Stefan Kost]

Hi all,

> 
>>you all know that the "Application Development Manual" and the "Plugin Writer's
>>Guide" contain redundant information and that this makes them hard to maintain.
> 
> [..]
> 
>>Therefore I would like to rename the "Application Development Manual" into
>>"GStreamer Architecture Manual" or
>>"GStreamer Core Manual" or
>>"GStreamer Architecture Guide" or
>> ... (suggestions welcome)
>>and concentrate all the information about elemnts, pipelines, schedulers,
>>dparams, ... there.
>>Finally we add a new documents called "Application Developer Guide" (ADG) that
>>focues on using gstreamer (e.g. setting up pipelines, using dparams, ...).
> 
> 
> I'm not sure this is a good plan. You're basically saying "we have an X
> document, so let's rename X to Y and create a new X document". I'm not
> sure if we need a core manual. If we do, then we'd need to write that
> newly.
> 
> The appdevman and pwg are separate entities on their own and require no
> previous knowledge. I think that's something that we should be very
> happy with and very proud of, even though the appdevman is currently
> outdated. Let's not throw that away.
Oh I don't want to throw things away.
> 
> I'd rather have someone update the appdevman. There's indeed some
> redundant information in the pwg and appdevman, but that's not bad. They
> have different focusses, and explain things in different ways. That's
> not bad at all.
Exactly and thats why it would be good, if these manual could focus on the
specific view, while the neutral concept will be described in the core manual.

The proposed reading order is: core, pwd, adm , as an app-developer will use the
core and plugins and a plugin developer will use the core.

A few examples:
Basic Concepts, both guides describe elements, padds, plugins, ...
If only that could be merged into one new GStreamer-Core Doc that would be
easier to maintain and could be referenced from both

Dynamic Params, Interfaces, Tagging, Clocks:
both app-dev and pwg needs to know what this is, then we can tell one part how
to provide them and the other party how to use them.

So I agree, we can avoid the renaming of the docs. It is more like refactoring
stuff into a new doc, the should be read prior either of the others.

> 
> Ronald
> 
> 

I am not convinced yet, that the ideas is not worth it ;-)

Stefan
-- 
      \|/            Stefan Kost
     <@ @>           private            business
+-oOO-(_)-OOo------------------------------------------------------ - - -  -   -
|       __  Address  Simildenstr. 5     HTWK Leipzig, Fb IMN, Postfach 301166
|      ///           04277 Leipzig      04251 Leipzig
| __  ///            Germany            Germany
| \\\///    Phone    +49341 2253538     +49341 30766101
|  \__/     EMail    st_kost_at_gmx.net kost_at_imn.htwk-leipzig.de
|           WWW      www.sonicpulse.de  www.imn.htwk-leipzig.de/~kost/about.html
===-=-=--=---=---------------------------------- - - -  -    -
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kost.vcf
Type: text/x-vcard
Size: 345 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20040720/99deba56/attachment.vcf>