[LAD] State of Plugin API's

Danni Coy danni.coy at gmail.com
Mon Nov 2 15:33:40 UTC 2009

Maybe it is worth looking at the extension model used in OpenGL.

Extensions are at first created as something vendor specific.

Widely useful extensions get reviewed by the architecture review board and
if deemed worthy become arb_extensions (this is now not essential to be
implemented but highly reccomended).

A lot of extensions eventually find there way into the core spec. Which
means that vendors have to implemented them to be compatible with that
version of the OpenGL specification.

Another approach might be to compile a list of stable extensions that should
be supported by a host. I would suggest that such a list would be compiled
once a year and that lv2_[year] could be used to suggest if a host should be
expected to support a particular extension. The time period could be longer
if necessary.

On Tue, Nov 3, 2009 at 1:08 AM, David Robillard <dave at drobilla.net> wrote:

> On Mon, 2009-11-02 at 08:48 +1100, Patrick Shirkey wrote:
> > On 11/02/2009 08:27 AM, David Robillard wrote:
> [...]
> > >> So what is your variant?
> > >>
> > > Time, effort.  Clearly. :)
> > >
> > > The rest is just excuses, really.  What is the point in sitting here
> and
> > > hypothesizing about what hypothetical problems might be deterring
> > > hypothetical unnamed developers?  This kind of braindead dead-end
> > > mailing list babble is exactly why LV2 has to be extensible in this way
> > > - the people who are actually about to do anything useful don't get
> > > bogged down by all the noise.
> > >
> >
> > Isn't that the only reason for being a member of this list?
> Heh.  Seems like it.  Talking about development is like dancing about
> architecture, perhaps :)
> > I can see that the above details could be made more obvious to the
> > casual developer. I will work on incorporating the details into the new
> > documentation.
> >
> > I'm starting to get the impression that what is really missing is not
> > just documentation but a complete documentation system. The average
> > developer will be coming from a proprietary world where companies have
> > invested a lot of effort to make the documentation accessible and in
> > addition there are several external web projects offering to fill in the
> > gaps as it can be a good little revenue earner with advertising and
> > google ads, etc..
> One cannot have a "documentation system" without documentation.  Work on
> adding documentation to plugin .ttl files is definitely worthwhile,
> based on the assumption that someone will use it for something later.
> There are also many half-assed extensions that aren't marked up nicely
> and need this done so they can fit in and be easily/automatically well
> documented and consistent etc.
> As far as user documentation (of plugins) goes, personally I think
> on-line documentation in hosts is 99999999999* more useful than any
> external documentation, including on the web.
> As for extensions and such, we just need good documentation.  Can you
> even define "a complete documentation system" in concrete terms? ;)  I'd
> say all that is needed beyond the automatically generated stuff is a
> smallish tutorial or two (some already exist) on the basics of LV2/RDF
> so people can understand the generated stuff.
> -dr
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev at lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20091103/ecc224b0/attachment.html>

More information about the Linux-audio-dev mailing list