>>> Maybe it would be good to just start writing the actual software, and to implement new suggestions or answers to the requirements, as they arrive? <<< I appreciate your enthusiasm, and have also felt the itch to start coding. But it would be big mistake, IMO. Until we can agree on what is required in a plugin spec, we shouldn't be writing code. The cost of a fixing a "requirements bug" after code has been written is exponentially higher than fixing a regular coding bug. Also, the plan is for specification and code to be written by an MMA working groiup. The ultimate aim is for GMPI to be a standard that is managed by an impartial trade association. While open source and group collobaration can (and should) be a part of this, the process needs to managed carefully. In our case, it means requirements and specs before code. Lots of people have made attempts at coding up yet another plugin API. That seems to be problem, and the primary motivation for this effort. -----Original Message----- From: Andrew "Silver Blade" Greenwood [mailto:lists@xxxxxxxxxxxxxxxxx] Sent: Monday, November 17, 2003 9:58 AM To: gmpi@xxxxxxxxxxxxx Subject: [gmpi] All this talk... Why not make a start? I've noticed that recently the mailing list has become a lot more active, to the point of me having to skim-read the emails to see what point was being made. I'm looking forward to GMPI becoming a reality, however so far it seems a lot of us disagree on various details. Maybe it would be good to just start writing the actual software, and to implement new suggestions or answers to the requirements, as they arrive? For example, a basic outline of prototype functions to be used in the GMPI API (there's a mouthful... gimpy happy?) could be created, to give an idea of what would be available to hosts. This could then be looked at by the mailing list members, and commented on, and revisions made. Once everyone was happy with that, you could move on to something else like implementing the different event types, or defining the type of a MUSICTIME constant or something. This may seem like a completely insane idea, but I feel that we may just end up constantly debating different issues, small and large, and end up having to deal with a gigantic bulk of ideas when it actually comes down to writing GMPI. And then, where do you start? Another reason I suggest this is that this approach has worked before - I occasionally tinker with a freeware Windows clone called ReactOS, which originally started in the form of a load of discussions, with no results. Someone else took over the project, and actually started coding. Since then, a lot of progress has been made. It's just an idea to try and get things moving along. Even if people could just post bits of code to the list for possible revision it might be good. ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- 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