== Quote from filgood ([email protected])'s article > Hi Adam, > Were you in the past not working on a Gui lib that did an a) type of thing? > IFAIR, The app ran on the server, the gui was on the client. Someone > could (via a client) connect to the app on the server, but have it > displayed locally?
There is the gdk broadway backend. Applications run on the server. The result is displayed in the browser http://blogs.gnome.org/alexl/ You can even display a browser in a browser. -------------------------------------------------------- For running the javascript apps on the client side there is qooxdoo. Communicates with the server with mostly JSON RPC with the "same source policy" (I've wasted a lot of time on that one) http://qooxdoo.org/ -------------------------------------------------------- And for running binaries on the client side with some form of shielding there is Google native client. http://labs.qt.nokia.com/2010/06/25/qt-for-google-native-client-preview/ > ~ filgood > On 13/06/2011 18:15, Adam D. Ruppe wrote: > > sclytrack wrote: > >> Like a replacement for HTML5 and javascript. > > > > You *could* make this work, but the language itself won't help you. > > > > There's two approaches: > > > > a) Run the code on your server and only output the display on the > > client's computer. Like an X11 application. > > http://en.wikipedia.org/wiki/X11 > > > > b) Have the operating system limit the D application. It's not > > really possible to filter out malicious D code. > > > > Someone could always call an operating system function directly, > > even marking it @trusted so it works in safe mode. > > > > > > But, if you configure the operating system the right way, you can > > make all those potentially nasty calls unavailable. Put an > > operating system level limit on file access, put up a network > > firewall, limit it's CPU time, etc. > > > > Most the newer HTML web browsers are doing this in addition to > > javascript. The same principles can be used on almost any program.
