Re: [LAD] State of Plugin API's

From: Patrick Shirkey <pshirkey@email-addr-hidden>
Date: Sun Nov 01 2009 - 23:39:41 EET

On 11/02/2009 08:06 AM, David Robillard wrote:
> On Mon, 2009-11-02 at 07:13 +1100, Patrick Shirkey wrote:
>
>
>> FWIW, I will try to bring this information out in a simple manner on the
>> wiki. If anyone has the time to think of a detailed method for handling
>> this please share. I will need a more advanced description of how it
>> needs to be executed and displayed to implement this quickly.
>>
> There's not really much infrastructure or detailed method involved,
> really. This is how it works:
>
> There are two kinds of things: plugins, hosts, and features.
>
> There are two types of relationship between plugins and features:
> supports, or requires.
>
> There is one kind of relationship between hosts and features: supports.
>
> Note that all of this information is trivial to extract from a plugin's
> data file, so compiling this kind of thing by hand is probably a really
> bad idea. Generated documentation is definitely the way to go. IMO
> non-machine-readable documentation of LV2 things is a bug in and of
> itself, docs should be in the .ttl and extracted into whatever human
> readable form is desired (including online, while the user is using
> things in hosts; think right-clicking a plugin or port and hitting
> "help")
>

This will be a priority for me.

> Encouraging people to host plugin bundles online and just throwing up a
> tool on lv2plug.in that you can point at them and get the pretty docs is
> probably a good idea. This is the way I am trying to encourage things
> with extensions - standardized bundles in a machine readable format
> usable by simple tools. As long as authors stick to conventions and
> don't make weird bundles for no reason, all this fancy documentation
> (and web retrieval, and whatever else) stuff is doable.
>
>

This will be a core function of the plugins site.

>>>> And, oh
>>>> yeah, we forgot to tell you about the dynparam extension... but I'm sure
>>>> you'll figure that out when things don't work."
>>>>
>>>>
>>> The host has all the information needed to report this explicitly to the
>>> user (you can't use plugin foo because this program doesn't support
>>> feature bar). Its not like it's just going to mysteriously not work,
>>> that's just bad host/UI design.
>>>
>> Is this method clearly defined in the online docs?
>>
> That plugins need to provide the information in this way and host must
> not do "try and see if it blows up" testing for features is very
> explicitly stated in the docs / specification itself, yes. The docs
> need to be put in a more prominent place though.
>
>

This information can be brought out into a more prominent location for
all the documentation.

Patrick Shirkey
Boost Hardware Ltd

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Mon Nov 2 00:15:04 2009

This archive was generated by hypermail 2.1.8 : Mon Nov 02 2009 - 00:15:04 EET