[gst-devel] Re: [gst-cvs] jdahlin gst-plugins: gst-plugins/ gst-plugins/sys/v4l/

[Gustavo J. A. M. Carneiro]

A Sex, 2004-08-13 às 19:27, Ronald Bultje escreveu:
> Hi,
> 
> On Fri, 13 Aug 2004, Johan Dahlin wrote:
> > > And how do we do runtime checks then? That's what GstImplementsInterface
> > > solves. Nothing more than that. GInterface doesn't solve it, so we need
> > > something else. What alternative solution did you have in mind?
> >
> > enum + set accessor:
> >
> > typedef enum {
> >   GST_V4LSRC_SUPPORTS_OVERLAY ...
> >   GST_V4LSRC_SUPPORTS_TUNER   ...
> >   ....
> > } GstV4lFeaturesMask;
> >
> > Public getter:
> >
> > GstV4lFeaturesMask gst_v4lsrc_get_features (GstV4lsrc *)
> >
> > and a private setter
> >
> > So if the user tries to call a xoverlay function on an element not
> > support it, it should either silently return a bad value or
> >  (preferably) raise an error of some kind, that can be catched by user
> > code.
> 
> That's insane. We're not at all talking about v4l here, but about the
> tuner interface which might or might not be implemented by element X,
> which could be v4lsrc, bktrsrc, xsrc, v4l2src, directxsrc or whatever
> other element you had in mind. Implementation is part of the interface (or
> a dependency, which GstImplementsInterface is) or it's not there at all.

  Allow me to intrude in the discussion. ;-)

  Regarding:

  "tuner interface which might or might not be implemented by element X,
which could be v4lsrc, bktrsrc, xsrc, v4l2src, directxsrc"

  Obviously, each such element should be registering its own GType, and
in that case it would be perfectly acceptable to add the interfaces that
are actually implemented in each element/type.  No need for any of these
crazy hacks.

  Just my 2 cents.  Regards.

-- 
Gustavo J. A. M. Carneiro
<gjc at inescporto.pt> <gustavo at users.sourceforge.net>
The universe is always one step beyond logic