[gmpi] Re: Reqs draft

  • From: Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Sun, 09 Nov 2003 08:48:00 -0500

>> Loading a dll is pretty lightweight.
>
>The DLL can be encrypted by an hardkey and may need nearly one second to be
>loaded. The DLL can be protected by different method (CD-checkup, network
>validation etc) that slowdown the loading process. 

ah, this is the core of the speed concerns, eh? so, to handle the
paranoia (somewhat justified paranoia :) of proprietary developers, we
have to introduce the inevitable problems that occur when you use an
external registry to maintain information. i have never heard of *any*
system that does this without problems. what happens on systems that
have both "system wide" plugins and "per-user" plugins? where is the
registry? how does the information get stored without collisions if
the user updates their personal copy of FooMatic, but the system still
has the older one installed? are there N registries? how are they discovered?

its a corner case, sure, but a corner case that stands directly in
front of the user, not off in a deep dark place where they won't see
it.

information that relates the plugin needs to be stored with the
plugin. as a compromise, i would accept the following idea: for a
plugin stored in a file called "foo", let there be another shared
object (DLL) called "foo-bar" (where the "-bar") is constant across
all foo. when a host discovers the plugin "foo", it actually opens
"foobar" to read metadata about "foo". "foobar" is small, and always
unprotected by any DRM system. how does it discover "foo" and not
think that "foobar" is a plugin as well? tricky, but perfectly
finessable if we were to agree on this general idea.
                                                    
>                                                   Plug-in DLL with graphics
>and so on can have a size of several MByte . Multiply by 100 or 200, you can
>eat all your memory for nothing.

AFAIK, all modern operating systems (windows included) do not allocate
memory for the data sections of a DLL until the relevant addresses are
touched. they *might* (if implemented badly) have to read the data
sections while loading, but it doesn't get loaded into memory at that
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

Other related posts: