Although COM on Windows has a central registry, COM binaries contain type metadata generated by an IDL compiler and bound into the executable. This metadata is, of course, actually quite independent of the Windows registry and can be read and understood without using the registry at all. One solution to our dilemma is to do exactly the same: bind metadata into plugin executables based on IDL with annotations as to capabilities. Hosts can locate and load this metadata without instantiating the plugin, and without even loading the executable AS a library but only as a regular file, and without using a central registry. A host with 100 plugins could read, parse, and tabulate this metadata in very short order. This metadata could even be XML as long as it is bound into the executable file. Template metaprogramming techniques could even be used to generate the metadata from the GMPI implementation classes, so that only a minimum of declarations, and not in separate IDL files but right in the C++ header files, would be required to generate and bind the metadata. I would only propose this solution if the actual loading of shared libraries to call capability query functions proved too slow. I propose that query functions be the only "metadata" part of the initial specification, and after a trial period, if they prove too slow, the specification be changed to require metadata to be bound into plugins (with a template metaprogramming reference implementation). Original Message: ----------------- From: Paul Davis paul@xxxxxxxxxxxxxxxxxxxxx Date: Mon, 10 Nov 2003 09:03:01 -0500 To: gmpi@xxxxxxxxxxxxx Subject: [gmpi] Re: Reqs draft >> you wanted GMPI to provide a way for hosts/plugins to write plugin >> info to a centralized location. if that location is system wide, then >> on any multi-user OS, there are permission issues to be resolved. if >> its not system wide, every user has to have their own "registry" >> whether they want one or not. > >i didn't say the oposite, we have just to decide if the GMPI installing >process is per user or per machine. The rest is taken in charge by the >system... i don't know of any other good software for multiuser OS's that enforce this choice. want to install acrobat on any *nix system? you can do it as a user (private copy) or as administator (system-wide copy). you can have multiple versions installed too. same for oracle, realplayer, maya, and many others. i mention these examples specifically because they are proprietary packages available only in binary format. there's no reason for GMPI to do anything different. users can install their own private plugins; administrators can install system-wide plugins. hosts should find them both. the question is: how? >Let's Add that this question has nothing to do with the fact we need a file >somewhere to give the available list of plug-in it has EVERYTHING to do with your preference for a file. if the host just scans N directories (aka "folders") looking for plugins, the mere existence of the plugin is enough to find each plugin (assuming that the search path is defined). if you add the requirement for each plugin to be registered somewhere other than in the filesystem itself, suddenly there has to be a mechanism to write to this registry, and to decide which registry if there is more than one. if you remove the use of the registry, this mechanism and policy decision are rendered unnecessary. >(in the registry or in a >regular file, i don't care , i just don't want to be obliged to load a DLL >or whatever executable code to get this list and further information about >the installed plug-ins). i don't think you've provided a good enough explanation of why loading the DLL is a problem. you've mentioned DRM, but david asked questions about when the decrypting occurs that still need to be answered in order to clarify how much of an issue this really is. remember, loading the DLL is not instantiation. we understand (now) that DRM can make instantiation slow, its not clear how much it affects loading. if it does, then we have to come up with a different solution. >blablabla, If you want to reply to the question explain us what do you do >when there is "clashes between the system registry and the user registry" >personnally i've replied that i don't want to enter in such consideration. if GMPI takes that approach, it will force situations on users in many contexts (academic institutions in particular) that will make their life unpleasant and difficult. i don't consider that acceptable, especially when it appears to be motivated by nothing more than an unwillingness to tackle the issue rather than any inherent technical issue. --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 -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ . ---------------------------------------------------------------------- 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