MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]
Guidelines for extensions.c and Server Packages
Erik wrote in "Re: New MOO Maintainer: Me"
> * Mix-and-match extensions. It should be possible to combine
> server extensions with a minimum of effort. We're getting
> there--extensions.c alone is a great improvement--but I think
> there's more to do. For example, I'd like to pursue the ideas
> for extension package format that came up in March on MOO-Cows.
> ThwartedEfforts's message
> http://forney.scinc.com/~abakun/moomail/96.03/msg00342.html
> is a good place to start reading that thread.
There were more messages on moo-cows related to this topic than the
two messages documented in the above reference. I merged the ideas
that four of us had and on March 14 I posted a proposal to moo-cows
for inclusion in the FAQ (see the attached file). If anyone is
interested, I can forward the original messages that lead to this
proposal.
My hope is that something close to this could be included with the
server package or at least in the MooCows FAQ. Comments on this
guideline would be nice, but please read the Purpose section and
keep-it-simple.
Using this guideline, here is a 'ls ext*' of my current server code
directory:
ext-do.README ext-fup.moo ext-stack.c
ext-do.c ext-list.README ext.mak
ext-fup.ChangeLog.txt ext-list.c extensions.c
ext-fup.README ext-pem.README extensions.faq
ext-fup.c ext-pem.c
ext-fup.copyright ext-stack.README
Best regards,
Bruce Rafnel
_______________________________________________________________________________
The goal of Computer Science is to build something that will last at least
until we have finished building it.
_______________________________________________________________________________
$Date: 96/08/14 10:10:37 $, $Revision: 1.5 $
$Source: /mnt3/aux2/cmsmud/lambda/master/extensions.faq,v $
Guideline for Extending the MOO Server with extensions.c
========================================================
Contributors
Bruce Rafnel <rafnelb@mayfield.hp.com>
ThwartedEfforts <abakun@scinc.com>
Richard Godard <godardr@jsp.umontreal.ca>
Michael Brundage <anomaly@u.washington.edu>
Purpose
To easily allow people to distribute extensions to the MOO server so
that the amount of file editing that needs to be done is kept to a
minimum.
To allow maximum package flexibility, this guideline only minimally
defines the "contents" of the files. Another guideline should be used
to address the naming conventions of functions contained in a package.
Guideline
---------
Terms
<PACKAGE> name of the package
<VER> version of the package (1.2beta, 1.2p3, etc.)
Distribution File Naming Convention
<PACKAGE>-<VER>.tar (can end in .Z, .gz, .zip, ...)
In order to make this easy to keep track of, extensions of different
types should not be distributed via the same tar file. For example,
if I distribute a series of list manipulation functions, they should
not be bundled with file manipulation functions.
File Naming Convention
ext-<PACKAGE>.README (tell people about the extensions)
ext-<PACKAGE>.c (contains C code for the extensions)
ext-<PACKAGE>.h (optional)
ext-<PACKAGE>.patch (optional - change other server files, but
extensions.c should NEVER be patched.)
ext-<PACKAGE>.ChangeLog.txt (optional - describe changes since
the initial release of <PACKAGE>)
ext-<PACKAGE>.moo (optional - sample MOO code (for use in-db)
demonstrating the use of <PACKAGE>)
ext-<PACKAGE>.api (optional - describing the public interface,
should others try to understand or
modify this server extension)
Ideally, extension packages should be designed so that they have a
minimum number of files and so that only the extension.c file would
need to be edited. If other files must be changed, design the
extension package so that these changes are as small as possible and,
if possible, use the "patch" program to create ext-<PACKAGE>.patch.
ext-<PACKAGE>.c
ext-<package>.c and other extension files should #include the
necessary header files they need to reference functions from within
themselves.
The register_<PACKAGE>() function should call the oklog() function to
identify the package and its version when the server starts.
ext-<PACKAGE>.README
This file should describe:
- the server version
- required patches
- other packages it is dependent on
- exact lines to put in the extensions.c file
- exact changes that need to be made to other files (optional)
Example
-------
To make an extension called 'foo':
foo-1.3.tar
ext-foo.README
ext-foo.c
ext-foo.README
The foo extension adds a function called foo() to the LambdaMOO v1.8.x
server. When foo() is called, it creates a generic foobar for the
named player and moves it to their contents.
To add the function foo() to your LambdaMOO server:
Add this line to extensions.c near the top with the rest of
defines:
#define FOO 1
Add this line to extensions.c near the top with the rest of
the includes:
#ifdef FOO
#include "ext-foo.c"
#endif
Add this line to the register_extensions function near the end of
extensions.c:
#ifdef FOO
(void) register_foo();
#endif
Remake the server, reboot your MOO, and enjoy the added functionality
provided by the foo() function. (Note: You might have to remove
extensions.o to force extensions.c to be recompiled.)
ext-foo.c
#include "bf_register.h"
#include "functions.h"
#include "my-ctype.h"
#include "my-string.h"
#include "bf_register.h"
#include "config.h"
#include "exceptions.h"
#define FOO-VER "4.2"
static package
bf_foo(Var arglist, Byte next, void *vdata, Objid progr) {
...
}
void
register_foo() {
(void) register_function("foo", 2, 3,
bf_foo, TYPE_ANY, TYPE_LIST, TYPE_INT);
oklog("Using Foo Package version %s\n", FOO-VER);
}
extensions.c
#define FOO 1
#include "bf_register.h"
#include "functions.h"
#ifdef FOO
#include ext-foo.c
#endif
void register_extensions()
{
oklog("Extensions:\n");
#ifdef FOO
(void) register_foo();
#endif
}
Home |
Subject Index |
Thread Index