Re: [LAD] LV2 dyanic manifest extension proposal

2008/6/8 Steve Harris <steve@email-addr-hidden>:
> 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?)

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?

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).

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)?

Ideas?

Stefano
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Sun Jun 8 16:15:02 2008