Re: [LAD] LV2 dyanic manifest extension proposal

2008/6/9, Steve Harris <steve@email-addr-hidden>:
> On 8 Jun 2008, at 12:51, Stefano D'Angelo wrote:
>
>> 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?)
>
> 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.

Ok.

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

Uhm, lv2.ttl doesn't seem to say anything about that.

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

Ok.

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

Ok, only one DynManifest.

If noone has any arguments against this extension, I'll "officially"
release it in a couple of days (with the adjustments outlined in this
thread, of course).

Stefano
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Mon Jun 9 12:15:03 2008