Are you gonna spend the time implementing it? Or pay the devs?

As in in case of webdip or my game?
In my game I am considering learning how to program it - I am using asp.net.
In case of webdip I assume the developers can figure it out : D

I'll let A_Tin_Can give you an official answer, but I think it really comes down to the fact that the site's code base is old and we've never had more than one dev (it was effectively zero for quite a while until a few months ago). A live press interface is definitely on the to do list, but it's a long list, and there are a lot of higher priority items on that list that would take a lot less time and energy to get working.

Oh - Ok, good to know. So there isn't a real con to that, except for the fact that it take time and effort, good to know. May I ask whether you plan to use WebSocket or some more complex implementations of HTTP?

That's something the actual dev (A_Tin_Can) would have to answer. I'm not well versed in the intricacies of internet protocols.

Ghug has it absolutely right. The primary reasons we don't use something like websockets are:

1) Websockets weren't widely supported when webdip was first written - I haven't checked, but it's possible that websockets didn't even exist then.

2) Changing to websockets would be a lot of work. It's a pretty big change- in addition to the new code, it would also require substantial changes to the way phase change/message notifications work internally.

That said, something that allows instant messaging and phase changes without refreshing the page is actually on the long term todo list. It would dramatically improve the live game experience.

With any feature changes, a big part of the development time is spent on testing. If we change the way notifications and message work, it would have to be 100% right before it was released for all gams. In addition to the testing during development, It would probably spend some time as a "beta live game" mode before being made permanent for all games.

tl;dr: For historical reasons, and because it would be a lot of work to change.

I tried and then got bored, because i could make neither heads nor tails of the code base.

Yeah, I know the problem with trying to improve something that already works, let alone fixing an existing code : D

Orath: To get started with notifications, you want to look at the send* methods of objects/members.php and for messages, you'll want to look at lib/gamemessage.php. There'll probably be misc changes in board/member.php. For the phase change, you'd need a hook in the process() method on the game class.

Note that this change would be substantial - it's probably not a good candidate for a first change.

Having worked with the code for a while, I can say this is probably the cleanest large PHP project I've yet worked with. In general, it's very easy to maintain and make changes, and the code layout is very nice. Like any large project, it all seems wrong at first, of course :)

In this case, though, we'd be changing the code to do something that it definitely wasn't intended to do. It's a difficult change, and would require a lot of thought to keep the code as clean as it currently is. For those reasons, I really don't recommend it as a first change.

Looks like websockets weren't even standardized until 2011, and the webDip code base predates that by several years.

@yassem:
Also, using websockets is not the only way to implement asynchronous communication with the server (i.e., for getting messages and game state changes immediately without having to refresh the page).

AJAX techniques could accomplish the basically same thing (at least from the user perspective), although there are technical differences in what's going on behind the scenes (e.g., long polling vs a true push).

Here is an interesting discussion on the topic of AJAX vs websockets:
http://stackoverflow.com/questions/10377384/why-use-ajax-when-websockets-is-available

However, just as with switching over to websockets, adopting AJAX techniques would probably require a similarly huge development effort involving modification of several core components.

^I agree with this.

I think the hard part is not which technology we use - the effort is in the (re)design for the necessary changes, and in testing.

Note: webDip already does use some AJAX techniques, but this is limited to the situation of submitting orders. However, broadening the usage of AJAX for other features would still require a huge amount of work, probably on the order of practically rewriting several core components.

Sure, Ajax is one of the possibilities for polling, but isn't that generally considered soon-to-be outdated? The effect for the user is the same, but the efficiency is much lower, isn't it. Nevertheless, I do understand the problems with implementation.

Outdated as in polling technique, not AJAX of course

@yassem:

*LONG* Polling, Comet, etc. are not the same thing as simple, repetitive polling. Basically, within the wide array of techniques that get thrown under the "AJAX" label, there are various methods that fairly effectively emulate the responsiveness and efficiency of server pushes.

Here is a page that might help explain things:
http://stackoverflow.com/questions/11077857/what-are-long-polling-websockets-server-sent-events-sse-and-comet

I would also recommend looking more into the wide breadth of AJAX techniques. AJAX isn't simply one method, but rather a catch-all label that has been applied to a wide variety of techniques.
Check out wikipedia and various tutorials on the web that you can find via google.


As for "efficiency" ... performance (latency, throughput, etc.) considerations are just one part of the larger set of design considerations that have to be made for choosing a solution. Client-side support, network/server support, and ease of integration into other frameworks are just some of the many of other design considerations that need to be made. For example, would a tiny fraction of second difference in message latency really matter for webDip? Or would it be more important to ensure that the feature works across more clients/networks?

Maybe you overlooked this link that I posted above, which explores some of the pros/cons of AJAX vs websockets:
http://stackoverflow.com/questions/10377384/why-use-ajax-when-websockets-is-available

In regards to AJAX vs websockets, you have to weigh these design considerations to figure out what might work best for you application/context. It would be foolish to simply say that one is objectively better than the other.


TL;DR: Read the discussion in two links that I posted above.

Long polling is awesome and easy to implement on the client side... But I don't like it as a server-side solution, because I don't know how to create a single thread to handle all the open connections... You end up with one process per page, and it just builds and builds... At least in php, I don't know how to pass a open connection to a list waiting for messages.

Not sure about a websocket alternative...