[gmpi] Re: Reqs draft
- From: Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Mon, 10 Nov 2003 09:03:01 -0500
>> 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
Other related posts:
