I insist that a native app could do a better job, and I've seen what Geofram suggests. (Don't take this wrong, this isn't a request.)

Well, of course, in principle a native app could just duplicate the interface through the best browser available.

The tricky question is, whether or not a native app could improve the interface far enough beyond what can be achieved within a browser in order to motivate the need for the creation of such an app?

As others have pointed out, a prerequisite of creating a native app would be server site work to enable the direct communication between the app and the server. Of course, one could implement the app as a translation/presentation layer that interacts through the website, however that approach may be cumbersome or limited.

^^Not to mention problematic if the web interface changes. And have you ever tried to intercept the AJAX calls in a browser using an embedded browser in the app? It's next to damn near impossible. No, what we would really need is a series of WebServices in the server that the client could talk to. I don't know if Kestas or anyone has written them yet.

I was thinking exactly the same. I would like to write a Diplomacy server in Java that allows players to join using their own client. But an important prerequisite for me would be that webdiplomacy.net would switch to using that server. Who exactly runs the server here? I would like to get in contact.

Kestas created this site and runs it.
userID=10

@yebellz - There isn't that much that would have to be changed if your app communicated through HTTP, using the same data currently loaded by AJAX?
Things like the forum/profile would need translating (or in the short term just loaded as HTML and parsed client-side) but you could make a working version of the site without too much change server-side.

I toyed with an iOS app for a while, but when I realised push notifications would be unavailable, there wasn't really that much of a point.

fig is right; the order entry stuff is done via JSON, so you could certainly interact with this site via another client if you wanted to. (Using a JavaScript engine on the client side, available in Java and Silverlight, you wouldnt even need to rewrite the order generation code)

@CathodioN: All I'll say is webdiplomacy's server-side footprint was about 30 KLOC last I checked. Rewriting it to get more flexible client support would be like coming up with a new mode of transportation because current cars dont have large enough cup holders

I have no problems entering orders with Android and the built in browser. Sometimes the chat box is a little off but in landscape mode it works better when you zoom in.

30 KLOC - including comments etc? I've never really known the neatest way of representing program size, so personally I tend to go for filesize, but it depends so much on the scenario.

Whilst I do agree that in general things are fine, it would be nice to put up a second front-end just as a data API. Things like this page, for example, could just be available as cached XML and people could then load that for their own clients (indeed this page itself could be rewritten to load from a server-side xml file).

[via AJAX or similar]

@Timmay, I agree, and I think some mobile targeted style sheets would definitely be the solution with the quickest, easiest results. Unless a web app aimed to have some kind of special functionality that a website couldnt have it'd be a hard sell (plus you'd need to write it for each platform)

@fig: Including comments and excluding brackets and whitespace IIRC, but whether it's 40 or 20 doesn't matter, it's just to give a sense of scale

Also yup it'd be nice to have everything doable via XML, but the main order entry, unit and map data (the hard stuff) is already doable in XML and/or JSON, and I'm not convinced a webdip app would need to access the forum.
Frankly I think anyone serious about making an app could easily map server-side stuff to use XML/JSON as necessary; it's just not something that needs intimate webdip knowledge