>> this provides, then a plugin throwing an exception will likely cause >> the program to abort. > >Even if the exception is caught within the plug..??? it would probably be OK in that case. >hmm, but libltdl itself contains platform specific code on the individual >platforms, it's just a standardized interface to a lib. in the end, you >can't get away from platform specifics SOMEWHERE along the line. oh sure, its just whether its explicitly present in the plugin/host (leading to errors by specific developers in its use, lack of cross-compilability, etc. etc), or easily available in a standard wrapper. anyway, this is generally a host-side issue. >> i can easily imagine completely platform independent code >> to load, create and initialize the DSP part of a plugin. > >OK.. perhaps.. but by sticking with the standard containers we also keep >support for the standard compile tools. Using something new would probably >mean writing new linkers... etc... far too much work imho. i wouldn't ever propose anything new! :) i just meant wrapping existing methods for various OS's in something simple and standard. >I'm inclined to think that creating a standard API for GMPI that goes >beyond plug<->host communications is a bit of a risky step in terms of >design.. however if others think it's justified I could find it >acceptable. host->get_current_time (); host->get_current_cpu_configuration (&conf); host->get_plugin_location (self); its just semantics :) --p ---------------------------------------------------------------------- Generalized Music Plugin Interface (GMPI) public discussion list Participation in this list is contingent upon your abiding by the following rules: Please stay on topic. You are responsible for your own words. Please respect your fellow subscribers. Please do not redistribute anyone else's words without their permission. Archive: //www.freelists.org/archives/gmpi Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe