>Peronnally i'd go further, i think that talking and talking without real >base (like source code sample or whatever project in progress) is useless. >And by experience, especially when the goal is to design a system-like >architecture (or a library , or whatever components which can be used by >third part), designing it without programming it, takes an infinite time. i broadly agree with this, and could never have written JACK (for example) using anything like the process we are using now. however, the essence of what i'm suggesting is to use *existing code* as a starting off point. we have at least 6 existing APIs that are "fully implemented", in use by many people for many different purposes, and available for criticism, etc. so what i'm suggesting really is to act as if the existing set of plugin APIs are the result of the coding effort that you and Michael are suggesting, and move to the next step which is critiquing them so that we can move on once again. the key element is that we use the GMPI agenda as a way to organize such criticism, and we do not simply take potshots at particular features of a given API. keep in mind that when it comes to acceptance, the process GMPI has been through will be at least as important as the technical details, and without acceptance, GMPI is a waste of everyone's time. --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