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 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?Heh. Seems like it. Talking about development is like dancing about
> >>
> > 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?
architecture, perhaps :)
One cannot have a "documentation system" without documentation. Work on
> 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..
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