Data model backend vs. interface
Warning, this idea is half baked at the moment as I'm still playing around with it conceptually:
I've been putting together a small demo app to get my head around Wt and I've basically got what I want working at this point. However my next project I'd like to be able to tie mobile devices running a native client, web browsers running a Wt interface and possibly a desktop client together using a single back-end and to what extent it is possible a single C++ code base. Specifically I'd like to build an interactive application where actions made on one screen show up for notifications on another screen. Has Wt been used for this kind of interactive behavior? The chat client seems to present a starting point but are there any suggestions / pitfall warning for decoupling the back-end data model from the front end? Would you be able to create some facsimile of this behavior using the DBO and a signal/slot system? IE, include a version entry in the DB scheme and if this version number is updated in an interface running in browser 1 issue a signal to update the widget in browser 2?
RE: Data model backend vs. interface - Added by Koen Deforche 11 months ago
I don't think there are hidden issues in moving the backend from the chat application to a separate process -- you should be able to keep the same API within the application (SimpleChatServer) but reimplement parts of this class to use a connection to another daemon.
As to using a database for this -- the problem is that databases do not have a standardized API for event notification. Postgres for example has something along these lines, but even then I'm not sure if it would be suited for this.