2 Nov
2009
2 Nov
'09
11:33 a.m.
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(a)drobilla.net> wrote:
On Mon, 2009-11-02 at 08:48 +1100, Patrick Shirkey
wrote:
Heh. Seems like it. Talking about development is like dancing about
architecture, perhaps :)
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? 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(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev