[LAD] LV2 dyanic manifest extension proposal

[Steve Harris]

On 8 Jun 2008, at 12:51, Stefano D'Angelo wrote:

> 2008/6/8 Steve Harris <steve at plugin.org.uk>:
>> On 8 Jun 2008, at 02:31, Stefano D'Angelo wrote:
>>>
>>> /* This function shall create a temporary file containing the  
>>> dynamically
>>> * generated manifest.ttl-like file and return a FILE pointer or  
>>> NULL in
>>> case
>>> * of failure.
>>> *
>>> * The generated file must not implement DynManifest classes. */
>>> FILE * lv2_dyn_manifest();
>>
>> Seems like a solid proposal. I'm not familiar enough with the  
>> extension
>> mechanism to know if you need some extra stuff to define the  
>> extension URI
>> and so, but the idea seems solid.
>>
>> One comment, it will be difficult for the plugin to know when it  
>> can clean
>> up the file. Obviously on UNIXy systems you can unlink it after  
>> returning
>> the FILE * to the host, and let the filesystem garbage collect it  
>> later, but
>> I don't think you can do that on Windows.
>>
>> Maybe it would be a good idea to provide a lv2_dyn_manifest_done()  
>> function
>> or similar, so that windows-based plugins can clean up their  
>> temporary
>> files?
>
> Agreed.
>
> Anyway I forgot to mention a couple of things:
>
> 1. A DynManifest is not a Plugin; Plugins and DynManifests can be
> found inside the same bundle's manifest.ttl file (which is maybe kind
> of lame?)

Nope, there's no reason to say where the declaration appears, you can  
link in more RDF files with rdfs:seeAlso if you with to, which is  
somewhat like #include.

> 2. I don't really understand how does the :binary property exactly
> works. I see the LV2 spec does not define it, but it is referenced
> inside manifest.ttl files as lv2:binary. Is that some kind of property
> belonging to some base class or...? And what if it is not present?

It has to be present, otherwise there's no plugin.

> 3. The binary property in the generated file should probably refer to
> the same binary .so file containing lv2_dyn_manifest* (opening other
> APIs' plugins should be done in lv2_dyn_manifest* itself IMO to avoid
> inconsistencies).

The binary that contains the lv2_dyn_manifest* stuff should be the  
same one as contains the run() IMHO.

> 4. What about multiple DynManifests in the bundle's manifest.ttl file?
> In case they refer to the same binary, should lv2_dyn_manifest_*()
> functions be called in the original order for lv2_dyn_manifest() and
> reverse order for lv2_dyn_manifest_done() (static data would do some
> trick in this case; this simplifies my own work somehow - modular
> wrapper - but maybe it's not that beautfiul)?

Can you think of a reason to have more than one? If not I'd say just  
say that there has to be one. It's simpler. BTW, you get no implicit  
ordering in RDF (it's a graph language), so if you want to order  
things you have to number them in some way.

- Steve