Njudge 2 discussion document

Version 1.0 Millis Miller - 11th September 2003 : original version

Version 1.1 Christophe Courtois - 12nd September 2003 : typos and personal ideas

Introduction

This document is a discussion document about the proposed updage of the existing Ken Lowe judge software, as found at http://www.njudge.org/, and hereafter referred to as njudge-1.

It was written in 'C' originally some fifteen years ago (a more complete history can be found at http://devel.diplom.org/Zine/S2002R/Miller/What_is_njudge.html).

With the passage of time, the code has become more and more difficult to maintain, and a general consensus seems to be being reached by the maintainers (defined as the members of the [email protected] mailing list) that the time has come for a re-write of the software.


Goals

“To produce a version of njudge that is easy to maintain, so that bugs can be simply tracked and fixed, and new features quicker to add.

To desing the code in such a way that it is well structured, using more modern software design techniques.

To maintain backwards compatibility with users, so that no noticable (or at least significant) change is detectable, and so that other programs or automations that rely on judge output continue to work.

To maintain backwards compatibility with existing judge data files, so that existing njudge-1 installations can be progressively upgraded with the minimum of pain and effort by their keepers.”



Programming Language

This is at present not completely decided, though a general intention has been stated for Perl. Other options might include:



Implementation Strategy

To lessen the burden and avoid a 'big-bang' effect, whereby a complete rewrite of everything would introduce a large amount of new bugs in all likelhood, with a perceived (if temporary) reduction in program quality, a phased approach would be better.

The strategy that the author suggests for this would be a gradual substitution of the dip program core functionality, followed by the replacement of the complete environment (rdip, flock and mail handling).

Dip Replacement

The njduge-2 dip program would work as a wrapper, which would prgressively implement more and more functionality. That which was not implemented would be passed to the njudge-1 dip program, which would handle existing functionality.

Essentialy, njudge-2 dip would process its defined set of commands, and pass to dip an input file where these commands were stripped out.

The phases would be:

Non-signon commands

Njudge-2 dip would handle commands that are not required inside a signon/create/signoff sequence. These are:



Signon command

In this phase, njudge-2 dip would check for valid signon/signoff commands. It would simply check that the player could signon, rejecting if something was wrong, or passing to njudge-1 dip if signon was ok (this is the only case when the command would still be passed to njudge-1 dip, to allow it too to check the signon, which should always work as it had already been validated).



Create command

Similar to the signon command in its implementation, it would obviously be responsible for creating the game and the associated data files correctly.



Set command

Basically, to implement the whole mess of commands that are currently performed in ml_set.c. The settings altered would be made to dip.master, so that when njudge-1 is invoked, changes are already performed.

Press commands

This means the broadcast and press to commands. Here, njudge-2 dip would take over the responsibility for press commands, with all the qualifiers currently allowed. At this point, njudge-1 dip would be doing ajudication and not much else



other commands

Here, other commands, that are not set, would be implemented. Examples are:

Note: The predict command would be left out, as this is more related to ajudication.



Ajudication

The biggie! Here, the ajudication would be ported to njudge-2. Possibly this too could be implemented in a phased manner, so that, for example, turn types are sepately implemented, i.e.:



Miscellaneous

This is basically to include the stuff not specifically covered yet, which may be includedin the phases above or may not. Specifically, I am thinking of such items as:



The Rest

At this point, njudge-2 dip is a fully functional program, being passed the mail input, altering internal data files accordingly and producing a mail output (byt this stage, it is assumed that a more simplified stream can be used, passing only the sender's address (email, IRC id or whatever) and subject in addition to the message content.

It then remains to substitute rdip, and the various other support scripts and programs, to make a new, cohesive whole.

(Obviously, this blabble needs to be replaced with a more definite plan at some stage :-) ).



CVS and Versioning Considerations

While then njudge-2 replacement program is in progress, it is planned that no new enhancements are made to njudge-1, only maintenace work. It may obviously occur that a bug is found in njudge-1 that needs to be fixed, and said bug then needs to be placed into njudge-2's remaining 'legacy' functionality.

This could be achieved by the use of branches in CVS, whereby one repository is used to hold both njudge-2 and njudge-1 code. Some experienced CVS users have indicated that this is not a very convenient way to work, overly complicating life.

Assuming that another versioning system is not to be used (the CVS replacement project Subvert still being fairly immature) it seems more reasonable to establish a separate njudge-2 repository, to which is copied a snapshot of njudge-1 sources, which are then whittled away as their functionality is slowly assumed by njudge-2.

If bug fixes are refused for implementation in njudge-1, and only made available in njudge-2, it would serve the dual purpose of reducing the development control overhead, and 'induce' judgekeepers to migrate early to the new code base.

Version Numbering

Though not an item of major importance, it can be discussed already the proposed version numbering scheme.

Njudge-2.0 seems a good target version for the completely rewritten judge. The intermediate judge, prior to this, would be njudge-1.9, with each phase being represented as a minor number, as in njudge-1.9.1 (which would include only handling of non-signon commands, as proposed earlier).

(Alternative : find a new name than Njudge, which stands for Nathan's judge?).



Long-term goals and ideas



Ideas:



Open points





Comments

This is a working document, with no one owner. Comments and updates are more than welcome, as long as the repository version is kept current.



Millis Miller

11th September 2003