[gmpi] Re: Reqs draft
- From: "Vincent Burel" <vincent.burel@xxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Sun, 9 Nov 2003 15:38:22 +0100
----- Original Message -----
From: "Paul Davis" <paul@xxxxxxxxxxxxxxxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Sent: Sunday, November 09, 2003 2:48 PM
Subject: [gmpi] Re: Reqs draft
> >> 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,
You have maybe the change to stay alive without saling any software , this
is not my case , sorry.
> 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?
What are you talking about !?.
> 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.
if you prefer that why not, personnally i prefer to deal with a central
datafile, with access function provided by GMPI to register the plug-in and
information in.
> > 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.
Sorry Paul, you are too much in the theoritical aspect, if you load a DLL,
it is to put it in memory , otherwise why loading a DLL !? well, If you
load all your VST's plug-in on your system without using memory, let us know
the method :-)
Vincent Burel
----------------------------------------------------------------------
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:
