Wt

Hello Garrett,

So why not implement your REST interface as static Wt resources?

Watch out to make your server push dependend on Websockets. While websockets are well supported in recent browsers, there's still a lot out there that don't, and even more proxies that don't support websockets. Provide a fall-back on plain http if websockets don't work.

In Wt, every tab in your browser is a new WApplication object now. However, there are plans to change that and allow multiple windows/tabs to share a sessions.

BR,

Wim.

Wim,

Thank you for the response!

Part of what I was thinking about with using Wt as the web front end assembler was to have it 'deal with' worrying about whether websockets are available or not to a given browser. In this way the web page would talk to the data resources the same way as any 'heavy' client (whether that's a desktop app or mobile client). It seems like wrapping this implementation in a WResource would be an effective way to do that, emitting a datachanged()(or setchanged) signal whenever new information is pushed from the socket server. However this seems like it's something I wouldn't want to do unless I was forced to fall back on it by a browser not supporting a direct socket connection. Of course that's based on my understanding of how WResource works which could be entirely incorrect. Would this be a situation where I would want to write the interface widgets to talk directly to the socket if it's possible but fall back to the resource when it's not, or is it possible to wrap a socket system entirely in a wresource so that it provides the other servers URL if websockets are directly available on the browser (or am I missing something entirely)?

It's good to hear that shared sessions are in the wings, I look forward to getting to try the feature when it's available.

-Garrett

I'm considering attendance at Alex's seminar later this Summer: http://www.siliconvalley-codecamp.com/Session/2013/look-ma-update-db-to-html5-using-c-no-hands

"Web landscape is changing rapidly; while AJA[X|J] was an improvement from the user interface responsiveness standpoint, the underlying data transport mechanism was still based on the request/response polling model. WebSocket specification removed the last obstacle... The session offers a practical solution to few acute problems -- delivering data from storage over the network to the web end-user seamlessly, efficiently and independently from transported data types."

It would be interesting to hear what Emweb thinks about this trend and the POCO framework Net Library.

Slides from a recent presentation elsewhere can be downloaded here: https://github.com/boostcon/cppnow_presentations_2013/blob/master/thu/DynamicCpp.pdf

Hi Brad,

We tend to see websockets as an implementation detail for Wt, and our MVC model doesn't require you to write REST services, be it over HTTP or websockets or whatever the next technology will be. As you probably know, enabling websockets on a Wt application is as easy as modifying a configuration variable in wt_config.xml, so you only have to change 'false' in 'true' in one place rahter than implementing a websockets version for every REST service you make available next to the standard HTML version (you'll still need a fallback, it's too early to assume that websockets is generally available - Wt does this automatically of course). Wt doesn't enable websockets by default because compression over webocket links is not yet properly standardized, making it a slower solution for some use cases, but it's worth trying it out to see what it does to your application.

POCO looks like are really nice library (I haven't used it yet), just like boost, Qt, and many others. Wt focuses on the web aspects and offers an integrated solution. We chose boost as our baseline library, as boost is a library collection which has in the past often served as inspiration for the C standardization committee (boost.thread, boost.shared comes to mind), but please feel free to use whatever POCO library you want to write your application in combination with Wt. Only a few boost classes make it to our public interface, those are usually expressed in terms of standard C (boost.signals, boost.any and boost.regex are exceptions, since we didn't have a standard C alternative). We want to give as much as possible freedom in your choice of C libraries that you combine with Wt.

BR,

Wim.