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@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@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev