[LAD] State of Plugin API's

[Patrick Shirkey]

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