Googled it:
http://web.inter.nl.net/users/L.B.Kruijswijk/

My own primary objection to this is the use of Java. Java is not in itself open source, despite being a freely available resource, and therefore to rely upon it seems to be to abandon open source as a principle rather than a definition.
More importantly, Java is not always suited to the user. Not only does it require download and installation of software other than a basic browser, it doesn't work fully on all systems; like mine for example.

So we have an adjudicator system that works fine, or will do in a while, and is easy and simple for the end user, relying only on having a browser that supports PHP.
What's the need to abandon all that work in favour of a generally less suitable program that, although further in development, has few, if any, features -that are needed- that can't be implemented into phpDip in time?

Alright, it was just a suggestion. These are just some random ideas that I am throwing out there. No big deal either way.

First of all, the Java processing can be done entirely on the server side (similar to what is done with PHP). The engine is decoupled from the GUI interface allowing the adjudicating engine to work with the current interface (with some work to integrate them of course). This shouldn't create any compatibility issues for the users. However, the Java GUI could be also be put on the site (in applet form) as an alternative interface for those who might prefer it.

As for feature support, the first major issue is rules compliance. The current version of PHPDiplomacy doesn't even allow support for convoyed attacks. JDip has full rules support and passes the DATC test cases. You are valid in saying that with time and effort PHPDiplomacy's engine will eventually support more of the rules.

JDip supports all of the popular variants and new variants can readily be added. The creator of PHPDip has even acknowledged that adding variants to PHPDip would be quite challenging since many things are hard coded.

One last thing, Java is a great freely available resource that many people, businesses and industries already rely on. Even the vast majority of cell phone games and apps are written in Java. I don't think using Java as the chosen development platform abandons the open-source principle. The standards for the Java language, virtual machine, compiler, and byte-code (compiled Java) are all available on Sun's websites. Although the virtual machine and compiler are not open-source, there functionality has become very standardized and transparent. Java (and PHP), although proprietary and not open-source, have become de-facto standards. By your same arguments, you might say that using PHP would be abandoning open-source principles.

Previously Java wasn't under an open source license, while PHP was. Now both are under the GPL license, so the fact that Java isn't open source isn't an issue any more. :) But even if Java had been open source when I first started I probably wouldn't have chosed jDip as a base.

I didn't want phpDiplomacy to be a project that duct tapes a whole bunch of other projects together, I wanted it all to be in one place so that there are no barriers to what I can change, and I can get it the way I like it. Some projects take a C adjudicator and a separate C map maker and put the two together with python scripts, but what if you decide you want the map to display something the adjudicator is doing in more detail? I just think this approach is messy.
Most web hosts don't even support JSP, even requiring PHP5, MySQL 4.1 and InnoDB narrows down the number of supported hosts hugely, but using JSP I wouldn't know where to look. I like phpDip to be reasonably portable and being all PHP is part of that.
Finally I think adjudicators require fascinating algorithms that I wanted the pleasure of coding, I didn't want to let Zach have all the fun :)

You might ask why would Zach have written his own adjudicator in Java when there was already a perfectly good C njudge adjudicator he could have used. Whatever his reasons were the end result is a fresh look at things and a great new piece of code that probably wouldn't be as good if he had taped existing projects together.
I want to look at Diplomacy from an easy to use, newcomer friendly, web perspective; a database driven, AJAX, "Web 2.0" sort of perspective, and I think starting over fresh is a better way to approach that.


On the DATC guidelines; phpDiplomacy will eventually support them, 1.0 won't be released until it's compliant with the guidelines. Kruijswijk has been bugging me about implementing them ever since I first posted phpDip 0.6 to rec.games.diplomacy ;) and he has been very helpful in pointing me in the right direction for when I get started on it.


On the variants; it wouldn't really be any more difficult to implement variants than any other major feature. There's nothing about phpDip's structure which means that it couldn't be done. You would probably only have to alter adjudicator/pregame.php to have units placed in the correct starting positions for the game, and make a few constants into variables, like the number of required SCs for a win or the map image used. Once the units are in their starting territories phpDiplomacy's existing code would mean that only the territories which link to those starting territories would be displayed to the end user. phpDiplomacy actually lends itself to easy implementation of variants, which is great because I never originally intented to include them. :)
The hardest part would probably just be entering the board data which is a table of territories and a table of how all the territories link, which let me tell you is a few hours of mind numbingly boring work. By comparison the actual coding to accommodate it wouldn't take long at all.


Hope that clarified things for you, regards,