Maybe it is worth looking at the extension model used in OpenGL.<br><br>Extensions are at first created as something vendor specific.<br><br>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).<br>
<br>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.<br><br>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.<br><br><div class="gmail_quote">On Tue, Nov 3, 2009 at 1:08 AM, David Robillard <span dir="ltr"><<a href="mailto:dave@drobilla.net">dave@drobilla.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Mon, 2009-11-02 at 08:48 +1100, Patrick Shirkey wrote:<br>
> On 11/02/2009 08:27 AM, David Robillard wrote:<br>
</div>[...]<br>
<div class="im">> >> So what is your variant?<br>
> >><br>
> > Time, effort.  Clearly. :)<br>
> ><br>
> > The rest is just excuses, really.  What is the point in sitting here and<br>
> > hypothesizing about what hypothetical problems might be deterring<br>
> > hypothetical unnamed developers?  This kind of braindead dead-end<br>
> > mailing list babble is exactly why LV2 has to be extensible in this way<br>
> > - the people who are actually about to do anything useful don't get<br>
> > bogged down by all the noise.<br>
> ><br>
><br>
> Isn't that the only reason for being a member of this list?<br>
<br>
</div>Heh.  Seems like it.  Talking about development is like dancing about<br>
architecture, perhaps :)<br>
<div class="im"><br>
> I can see that the above details could be made more obvious to the<br>
> casual developer. I will work on incorporating the details into the new<br>
> documentation.<br>
><br>
> I'm starting to get the impression that what is really missing is not<br>
> just documentation but a complete documentation system. The average<br>
> developer will be coming from a proprietary world where companies have<br>
> invested a lot of effort to make the documentation accessible and in<br>
> addition there are several external web projects offering to fill in the<br>
> gaps as it can be a good little revenue earner with advertising and<br>
> google ads, etc..<br>
<br>
</div>One cannot have a "documentation system" without documentation.  Work on<br>
adding documentation to plugin .ttl files is definitely worthwhile,<br>
based on the assumption that someone will use it for something later.<br>
There are also many half-assed extensions that aren't marked up nicely<br>
and need this done so they can fit in and be easily/automatically well<br>
documented and consistent etc.<br>
<br>
As far as user documentation (of plugins) goes, personally I think<br>
on-line documentation in hosts is 99999999999* more useful than any<br>
external documentation, including on the web.<br>
<br>
As for extensions and such, we just need good documentation.  Can you<br>
even define "a complete documentation system" in concrete terms? ;)  I'd<br>
say all that is needed beyond the automatically generated stuff is a<br>
smallish tutorial or two (some already exist) on the basics of LV2/RDF<br>
so people can understand the generated stuff.<br>
<font color="#888888"><br>
-dr<br>
</font><div><div></div><div class="h5"><br>
<br>
_______________________________________________<br>
Linux-audio-dev mailing list<br>
<a href="mailto:Linux-audio-dev@lists.linuxaudio.org">Linux-audio-dev@lists.linuxaudio.org</a><br>
<a href="http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev" target="_blank">http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev</a><br>
</div></div></blockquote></div><br>