[gst-devel] cleaning up

[Andy Wingo]

Waddup,

On Wed, 2005-09-07 at 10:31 +0200, Stefan Kost wrote:
> please vote and state you position ;)

+1, -1 normally isn't a good way of deciding things, of course.. but
discuss we will!

> 1.) move gst/base/gstadapter.{c,g} back to gst/ or even to gst/utils/
> rationale: the adapter is a utillity class. it is not supposed to be derrived 
> from. an element will never *be* an adapter, but rather *have* one.
> If we find more similar classes it might justify the creatiion of a 'utils' subdir.

(CollectPads is a similar class.)

Welll ll l llll llll  I asked Wim about this actually the other day. His
view of libgstbase is that it is a library to help make elements on top
of gstreamer. Part of the library is a class library, and part is helper
objects. (I am paraphrasing his view because he's out of town atm.) Also
consider that the implementation of e.g. collectpads as a helper object
is related to the lack of multiple inheritance.

There is a certain elegance in keeping the core very orthogonal. For
example some of the useful^Wnon-orthogonal functions were split out into
gstutils.[ch] because they're not strictly necessary. Adding more code
to the core is a bit distasteful in this light. OTOH adding more shlibs
has its own unpleasantries.

Given the tradeoffs, wim felt it was best to put it in gst/base. That
way the core is kept trim, but plugin authors still have easy access to
the functionality.

I would be inclined to keep it in base, perhaps with a modification of
the libgstbase docs giving it a wider scope (classes of general utility,
whether as base classes or helper objects).

> 2.) rename gsttag.{c,h} -> gsttaglist.{c,h} and gsttaginterface.{c,h} -> 
> gsttagsetter.{c,h}
> rationale: sync filename with docs-module-name and symbol-prefix. makes it 
> easier to find.
> question: cvs surgery (problem if one checks out older versions) or delete+add 
> (loses history)
> 
> 3.) split gsttypefind.{c,h} -> gsttypefind.{c,h} and gsttypefindfactory.{c,h}
> rationale: two things in the same module

Looks fine by me

Regards,
-- 
Andy Wingo
http://wingolog.org/