X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~mdw/git/disorder/blobdiff_plain/b30155e30c466ce8ca8668b909a5daca7acfbfd5..0590cedca75c01811972b2f694f60f24028ee973:/README.developers diff --git a/README.developers b/README.developers index f7d9cfd..3302f5a 100644 --- a/README.developers +++ b/README.developers @@ -21,7 +21,8 @@ Building: * Compiled versions of configure and the makefiles are including in bzr, so if you didn't use a source tarball, you must start as follows: - bash ./prepare -C + bash ./prepare + ./configure -C make * On FreeBSD you must use gmake. @@ -64,10 +65,13 @@ APIs And Formats: The Server: * The server's command implementations must not block. Waiting for a little - disk IO is OK but blocking on long-lasting transactions or external - resources is not acceptable. Long-running subprocesses should use - subprograms (rather than forking but not execing) if reasonably possible; - see c_stats() for an example. c_reminder() is probably in the grey area. + disk IO is OK but blocking for extended periods on long-lasting + transactions or external resources is not acceptable; it will wedge the + server for all other users. + + Long-running subprocesses should use subprograms (rather than forking but + not execing) if reasonably possible; see c_stats() for an example. + c_reminder() is probably in the grey area. * The server process does not use threads and I would like to keep it that way. @@ -117,7 +121,8 @@ The Server: Web Interface: * The web interface does not use Javascript or Flash and I would like to - keep it that way. + keep it that way. Clever use of CSS is OK provided it works well on the + mainstream browsers. * I know that the web template syntax is rather nasty. Perhaps it will be improved in a future version. @@ -140,13 +145,24 @@ Disobedience: * Update doc/disobedience.1.in for any changes you make. +New Platforms: + + * It is not mandatory to have an entry in configure's 'case $host' section, + but may well be convenient. + + * Complete support for a new platform implies updating scripts/setup.in and + scripts/teardown.in as well as getting the software to build and work (but + this doesn't mean that patches that don't achieve this will be rejected). + Code And Patches: * Please follow the existing layout conventions. * Please try to write doc comments for new functions, types, etc using the same syntax as the existing ones. Doxygen can be used to turn this into - reference documentation. + reference documentation (see http://www.stack.nl/~dimitri/doxygen/) but + really the point is to have good inline code documentation, not the + Doxygen output as such. * More importantly, new configuration directives, protocol commands, interface features etc should be documented in the relevant places.