[gst-devel] Fwd: Re: [UCI-Devel] Re: Common Opensource codec API

[Ronald Bultje]

Hey Toby,

On Mon, 2003-06-30 at 20:48, Toby Hudon wrote:
> Is one function simple enough? ;)
> 
> Seriously, do(UINT msg, pDOC data); That's it. Internal switch
> on the message to handle the data if needed. If you don't support a
> given message in the API, you go to the default case which is
> return(0). Whoever called you has the job of handling an unexpected
> return(0), such as trying an alternate method, and if they can't
> they also return(0) and pass it up the call stack until it gets to
> the application, which either decides to try something else or
> returns a message saying not supported or error or whatever is
> appropriate.

The only thing that this solves is the API linking issue. And that's not
an issue anyway if we're going to define a standard API.

> That's it, two functions. The complicated part is in defining
> the messages and their data, but as long as each component is only
> required to support the messages it can do something with, and not
> handle exceptions, it should be easy for component developers.

But that's the whole issue, the messages. You're just moving the problem
over from linkage space to message space. The problem here is actually
to define how all this works. ;).

Funnily, you're taking XVID as an example, but xvid is horrible. Look at
the API. There's one struct per message. No extendibility. No
configurability. Perfect for a one-task API, but not at all usable for a
generic API.

GStreamer (GObject)'s way of defining all this is easier. Make
name/value pairs, make a standard doc that describes which types support
what base properties. Since there's no limit on name/value pairs,
there's no limit in extendibility. Making this two-way allows the
application to view these properties, too.
And, even better, this method doesn't depend on GStreamer or GObject at
all. GStreamer just implements it in that specific way.

The good thing of your approach is actually its simplicity, and I like
that. However, I wouldn't vote for sticking to one function, since that
only moves the definition problem over from linkage space to message
space, and that has no advantage, imho. However, the idea of using as
little functions as possible up to a certain amount sounds good, I'll
try sticking to that. :).

> If you have a simpler idea please let me know, and BTW what is 
> CORBA?

Something like COM, but for Unix/Linux.

Ronald

PS Christian, you've asked me to come up with a document, I'll try to do
that in the course of this week. Give me a few days, I have a job, too.
;). I'll take some ideas from the list and mix them together with some
of my own.

-- 
Ronald Bultje <rbultje at ronald.bitfreak.net>