[gmpi] Re: Instruments done, moving on to "Plugin Files"

  • From: Tim Hockin <thockin@xxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Mon, 13 Sep 2004 19:28:59 -0700

On Mon, Sep 13, 2004 at 09:37:21PM -0400, Paul Davis wrote:
> >>  Req 84:   Plugin files must be bundled into a single file on the
> >>  filesystem.
> >
> >This has had a lot of argument, and I think has more or less been shot
> >down.  Bundling everything into a single file (.jar was suggested) has

> its way, way to expensive. i don't know about the windows situation,

Agree

> >Instead of bundles, we can require that an on-disk plugin actually be a
> >directory containing the plugin shared object(s) and any associated files

> much better. quick pass at wording:

Will merge, unless I get objections.

> >My position (I think) is that metadata belongs in the shared object.
> >Whether you access the data via open() and read() or you have load and
> >call a probe entry point is irrelevant.  Probing should NOT be done on
> >every startup, and I think it is perfectly reasonable to expect a host to
> >cache the results of a probe.
> 
> i don't agree. its not reasonable to expect hosts to know how to
> parse ELF, COFF, a.out or whatever the flavor the month for shared
> object files on each platform is. the metadata needs to be placed in a
> file with a common format across platforms, thus leaving the handling
> of the shared object file to platform-specific calls (such as dlopen()
> on posix-ish systems). 

Well, there are two answers - one is that we build the meta-data as ASCII
text in the object file, so that it's easily findable, but not very
elegant.  The other is that we actually incur the cost of a dlopen() and
probe() call.  As you point out, most hosts will cache this, so the "it's
so slow" argument holds no water.

I don't believe that hosts will all abandon their own proprietary caches in
favor of these GMPI metadata files, either.  So hosts are going to read
this data, reformat it and save it again.  Further, some plugins (like
wrappers) need to be dynamically probed.

I'm still willing to consider the compromise of "if there is no metadata,
then you must probe" if I HAVE to, but I find dualities like that to be
silly and a symptom of design-by-committee.  We are designing with a
committee, but I think we can do better than being obvious about it :)

> >>  Req 90:   It must be possible to have two plugin files with the same
> >>  file name in two different directories.
> >
> >Does this need more expansion?  Or should it be bundled into the "plugin
> >directory" req?
> 
> I don't even understand where this is coming from ...

I think that the point was that hosts can not *just* use a dll name as a
key.

        foo/demoplug.dll
and
        bar/demoplug.dll
may both exist on one system, and the host must be
able to tell them apart.  Maybe it's a useless req?

----------------------------------------------------------------------
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:

  1. Home
  2. gmpi
  3. Archive
  4. 09-2004