Re: [SERVER] proposal for extensions.c

• Date: Tue, 19 Mar 1996 10:38:24 PST
• From:
  Bruce Rafnel <bruce@hpsdce.mayfield.hp.com>
• Reply-To:
  rafnelb@mayfield.hp.com
• In-Reply-To: <v02140b03ad73a9cfc881@[10.0.2.15]> (godardr@jsp.umontreal.ca)

I like it; great work!

I agree with Richard's suggestion to use ext-foofunc.c.
To be parallel, how about also using: ext-foofunc.README?
Good point about patches should not modify extensions.c.

Submitted for comment: I've summarized this packaging method for
server extensions. After reaching consensus (and some cleanup), maybe
we could get this added to the FAQ: "How to extend the server (adding
functions and packages)."

> From: ThwartedEfforts <abakun@scinc.com>
> Subject: [SERVER] proposal for extensions.c
> Date: Mon, 18 Mar 1996 14:53:03 PST
>
> Richard Godard and I have been talking about how 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 minium.

<PACKAGE>: name of the package
<VER>: version of the package (1.2beta, 1.2p3, etc.)

1) Tar file named: <PACKAGE>-<VER>.tar (can end in .Z, .gz, .zip, ...)
2) Tar file contains:
	ext-<PACKAGE>.README	(telling 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)

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

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 extention package so that
these changes are as small as possible.
Perhaps these changes could be put in a patch file:
ext-<PACKAGE>.patch.

The register_<PACKAGE>() function should call the oklog() function to
identify the package and its version when the server start.

The ext-<PACKAGE>.README should describe:
	- the server version
	- required patches
	- other packages it is dependent on
	- exact lines to put in the extentions.c file
	- exact changes that need to be made to other files (optional)

> For example, I make an extension called 'foofunc':
  % tar -tvf foofunc-1.3.tar
  -rw-r--r--   1 abakun/users          83 Mar 18 13:42 ext-foofunc.README
  -rw-r--r--   1 abakun/users       10240 Mar 18 14:14 ext-foofunc.c
> 
  The contents of ext-foofunc.README
> ---
> The foofunc 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 the includes:
 	#include "ext-foofunc.c"
> 
> Add this line to the register_extensions function near the end of
> extensions.c:
> 	(void) register_foofunc();
> 
> Remake the server, reboot your MOO, and enjoy the added functionality
> provided by the foo() function.
> (Note: You might have to remove extensions.o)
> ---

  Obviously, ext-foofunc.c and other extension files should #include the
> necessary header files they need to reference functions from within
> themselves.

> Patches to the server in general are still best distributed as patch
> files, to be applied with the patch command.  extensions.c should
  NEVER be patched.

• Re: [SERVER] proposal for extensions.c
• From: Michael Brundage <anomaly@u.washington.edu>

• Re: [SERVER] proposal for extensions.c
• From: godardr@jsp.umontreal.ca (Richard Godard)

• Prev: [SERVER] proposal for extensions.c
• Next: Re: [SERVER] proposal for extensions.c
• Index: MOO-cows
• Thread: MOO-cows