>>> Req 5 - Portable Runtime The GMPI design group should research options for a cross-platform portability library for GMPI plugins. And existing library may be adopted, or a new library may be drafted. This should be a separate specification from the GMPI API. Plugins that wish to be most portable should use this API instead of native APIs whenever possible. This API is not the host services API, which should handle certain host-specific services tasks. <<< To me this is drifiting away from the whole reason for wanting a runtime system. At least it's drifiting away from *my* reasoning. We need a way for plugins to allocate memory, access the disk, and manage threads, in a way that allows the host to manage and/or intervene. The host might the OS, or the host might be the host application. In other words, when a GMPI plugin needs to allocate memory, it asks the host for it. The host exposes a memory allocator for the plugin. The plugin doesn't have a memory allocator compiled in, because that means different hosts can't customize allocations to their requirements. To me, the requirement is: the GMPI host interface must expose core services to the plugin: memory management, disk IO, threading. It is the responsibility of every GMPI host to expose these services. A deliverable in the final GMPI developers kit will be reference implementations of these services for hosts to expose to plugins. ---------------------------------------------------------------------- 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