# Plugin interface

Erik Ostrom (eostrom@research.att.com)
Wed, 16 Jul 1997 10:17:12 -0400

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    > Some enhancements that might make this system adaptable to a wider
    > variety of plug-ins include the ability to "register" a function to be
    > called in the server main loop

    Can you (or someone else) give some examples of what this would be used
    for?  That would help in coming up with a good design.

    > Another possibility would be to create a configuration file similar to
    > the configuration files that fill /etc on UNIX machines, allowing
    > system-specific information (such as root directories for FUP) to be
    > specified at load-time.

    Would it be reasonable to put these in the plug-in directory?  So,
    you would have something like FUP.so (the plug-in library) and FUP.cfg
    (the configuration file)?

    Three more items:

    1. Is there someone out there who knows a lot about the state of dynamic
    loading on UNIX?  E.g., what systems support it, how similar are they,
    and, well, how many different versions of it would have to be maintained
    in the server?  If there are too many different APIs out there, and
    in particular if there are APIs that are idiosyncratic to a system I
    don't have ready access to, I might need to enlist some people's help
    in porting DLL support.

    2. As it happens, my current project is making it easier to add data
    types to the server.  It's now possible to add a simple data type in
    its own file by hacking only the Makefile and one C file that lists
    the types to register.  There's a natural tie-in with plug-in libraries.
    Plug-ins would provide a way not to have to hack that C file, and
    probably not the Makefile either; new data types make it reasonable
    to design certain server extensions better than they might otherwise be.

    3. It's possible that we don't want new functionality to keep on filling
    up the global built-in function namespace forever.  It's been suggested
    that plug-ins could take the form of "native objects" or "native methods"--
    that is, from the database side, using a new function would look like
    a verb call, but it would be implemented in C (or some other native-
    compiled language).  This may be orthogonal to plug-in design, but it's
    probably worth thinking about some.

    I know Chris Unkel, at least, has thought about how to do dynamic loading
    under Windows, so perhaps we'll hear from him soon.

    --Erik