Best way to write plug-ins?

[Jeff Garzik]

I am writing an application for a my company, and I am interested in
making it very easy to hook into internal program data (like a
PhotoShop Plug-In, if you know what one of those is). What would be
the best way to do this?

I can only think of two ways to do it right offhand, but I would like
to avoid the second (call me a purist):

* Allocate shared memory to a child process, which is either an
a.out or ELF binary.
* Write the data out to a temporary file, or pipe, which the child
executable then reads.

Is there a better way?

Thanks,
Jeff

--
Ask not for whom the telephone bell tolls ... if thou art in the
bathtub, it tolls for thee.

[Peter Mattis]

In article <3u7amh$h...@felix.cc.gatech.edu>,

Jeff Garzik <jga...@cc.gatech.edu> wrote:
>I am writing an application for a my company, and I am interested in
>making it very easy to hook into internal program data (like a
>PhotoShop Plug-In, if you know what one of those is). What would be
>the best way to do this?
>
>I can only think of two ways to do it right offhand, but I would like
>to avoid the second (call me a purist):
>
>* Allocate shared memory to a child process, which is either an
> a.out or ELF binary.
>* Write the data out to a temporary file, or pipe, which the child
> executable then reads.
>
>Is there a better way?

Well, I'm currently writing an application that uses plug-in modules. The
technique I use is to use pipes to handle communication and to use shared
memory to pass large data structures back and forth. (Well, I guess they
aren't really "passed" when using shared memory, now are they. :)

It is, however, not very easy to hook into internal program data. I set up
a fairly simple message passing system to handle requests for data. It works
fine for my purposes, but it wouldn't easily expand to allow access to
arbitrary data structures in the main application.

Mail me if you want more specifics.

Peter Mattis
pe...@soda.csua.berkeley.edu

[Randy Chapman]

My recommendation would be to investigate the libdl library from ELF that
allows for easy dynamic loading. I believe (but am not at all sure),
that data references back ot the main app work fine.

--randy

In article <3ua2hd$b...@agate.berkeley.edu>,

[Thomas Malik]

Another way would be to make use of ELF's fabulous dynamic linking
facilities:

1. make object files from your
2. use dlopen() to open an compiled (object) file
3. use dlsym() to get the address of functions from the opened
object file.
4. use the address to call your function you just loaded from the
object file.
5. use dlclose to get rid of the module.

See the man pages for these functions (note that they aren't there on
a non-ELF system).

This makes any data passing easy, since the modules are linked against
the main program, so you may use any global variable/function from the
main program in your modules.

--

===============================================================================
|
_/_/_/_/_/_/_/_/_/_/_/ _/ _/_/ |
_/ _/_/ _/ _/ | Thomas Malik
_/ _/ _/ _/ _/ | ma...@serv-400.dfki.uni-kl.de
_/ _/ _/ _/ | ma...@sun.rhrk.uni-kl.de
_/ _/ _/ | Berliner Str. 5-11
_/ _/ _/ | 6750 Kaiserlautern
_/ _/ _/ | (0631) 79868
_/ _/ _/ _/ _/ |

[Greg Hull]

What about sockets?

Then your "plug-in" apps wouldn't even have to run on the same machine as the
main application (unless you used AF_UNIX sockets)..

Write a Server that keeps track of everything that needs to be shared by
various "plug-ins" and then make each "plug-in" a client. You can create your
own little binary language so that all of the plug-ins and communicate back
and forth..

--
Greg Hull
Northeastern Men's Heavyweight Crew
SDRC/CASE QA.