2008/6/9, Steve Harris <[EMAIL PROTECTED]>: > On 8 Jun 2008, at 12:51, Stefano D'Angelo wrote: > >> 2008/6/8 Steve Harris <[EMAIL PROTECTED]>: >>> 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@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev