>What I'm saying is, there are much more important things to do here. >COM is very simple, one class with 3 functions, with the convention of >using a certain ID format (GUIID). > >I understand it's difficult to accept a new concept that's just 'thrown' >at you. And that it seems safer to re-implement it yourself so as to >completely understand it. But we're talking about the technique adopted >by Mozilla (the cross-platform open source browser). They had the same >discussion we're having. They're competent, knowledgeable people. They >chose COM, they didn't waste time and energy reinventing it. I'm quite willing to go down the COM route, especially after your excellent distallation of what its really all about. What troubles me (and it might trouble other people here who come from a *nix dominated background) is more subtle. One of the historical aspects of the *ix's close relationship with C is that the OS API is very simple, and looks like C. It has very few types in it that are not C builtin's, and those that do exist are very simple data aggregation structures. All structures are used as struct foo, never foo_t; By contrast, anyone who has been keeping even half an eye on the win32 API over the last 15 years (win3.1, for completeness) will be aware of the growing colossus-like nature of the API, with dozens of win32-defined types that are used all over the place rather than simple C builtins, all kinds of interface details that have nothing to do with the language, and so on. Now add even a smattering of C++/OOP, and you end up with an API that requires quite a deep analysis before you can begin using it. This is not unjustified, and in fact even the *ix'es are faced with the need for this kind of system as attempts to define "desktop environments" (which are essentially layers on top of POSIX in the same that win32 is a layer on top of the NT kernel API) grow more and more complex. But I know that for myself, having been exposed to the marvelous simplicity of a POSIX-style API, its incredible longevity (parts of it are more than 30 years old now and still unchallenged) and all the incredible software that has been built with such things, I am very wary of developing an API rich in new datatypes, new interface styles, and so forth. To me, the VST API, for all its lack of specifications, strikes just about the right balance here. Very few new types, a very simple definition in C, and a simple layer on top in C++. You can grok the whole thing in a very short time, and there's no "depth" to it. Contrast that with: HRESULT CreateFactory( CLSID clsidClass, IFactory** ppFactory ); HRESULT? CLSID? IFactory? Hungarian naming? There's nothing wrong with any of these conventions, and if you're a win32 programmer, you probably won't even notice them. But to me, this is already taking on the trappings of a baroque, complex API. --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