SCGUI gives you a wide range of response options to optimize the interaction between the client and the server. This allows it to be "tuned" to run on a variety of networks, with differing bandwidth and response time delay profiles. It can run on fast networks, or slow networks. (However, it is not optimized for high-speed games. It is mostly intended as a business tool.)
Turing-Complete languages also often need constant updating because new bugs or security holes are always being found. SCGUI avoids being Turing-Complete to avoid or reduce these problems.
Some client-side scripting is probably inevitable for some applications or needs, such as when responsiveness is valued over security for whatever business reason. However, it should be considered only an option when the protocol is designed. In other words, the focus should be on script-free-client applications, with client-side scripts viewed as a bonus instead of a necessity.
Another thing to notice is that almost every operation can be represented with these four elements:
The forest-view philosophy of SCGUI is to have as much of the processing take place on the server as possible, but without significantly affecting or slowing the user experience regardless of network protocols or network speed being used. SCGUI puts into a protocol what it needs and only what it needs to achieve this. It is a tricky balancing act, but SCGUI is up to the task.
<SCGUI@CLIENT FORMID=formpw CONTENT="Enter Password"/> <SCGUI@CLIENT FORMID=formpw WIDTH=300 HEIGHT=200/> <SCGUI@CLIENT FORMID=formpw WIDGETID=label1 WIDGETTYPE=label X=2 Y=30 VISIBLE=full CONTENT="Username:" /> <SCGUI@CLIENT FORMID=formpw WIDGETID=label2 WIDGETTYPE=label X=2 Y=60 VISIBLE=full CONTENT="Password:" /> <SCGUI@CLIENT FORMID=formpw WIDGETID=label3 WIDGETTYPE=label X=2 Y=90 VISIBLE=full CONTENT="Save Password:" /> <SCGUI@CLIENT FORMID=formpw WIDGETID=username WIDGETTYPE=textbox CONTENT="Bob" X=130 Y=30 VISIBLE=full /> <SCGUI@CLIENT FORMID=formpw WIDGETID=passw WIDGETTYPE=password X=130 Y=60 VISIBLE=full /> <SCGUI@CLIENT FORMID=formpw WIDGETID=keeper WIDGETTYPE=checkbox X=180 Y=90 VISIBLE=full CONTENT="Yes" /> <SCGUI@CLIENT FORMID=formpw WIDGETID=cancelbut WIDGETTYPE=button X=100 Y=140 VISIBLE=full CONTENT="Cancel" ONPICK=event /> <SCGUI@CLIENT FORMID=formpw WIDGETID=loginbut WIDGETTYPE=button X=150 Y=140 VISIBLE=full CONTENT="Log In" ONPICK=widgets /> <SCGUI@CLIENT FORMID=formpw VISIBLE=full/> TALKING TO SERVER ----------------- Example: User keys in values and presses the "Log In" button: <SCGUI@SERVER FORMID=formpw WIDGETID=loginbut EVENT=onPick/> <SCGUI@SERVER FORMID=formpw WIDGETID=username CONTENT="Bob"/> <SCGUI@SERVER FORMID=formpw WIDGETID=passw CONTENT="foobar"/> <SCGUI@SERVER FORMID=formpw WIDGETID=keeper CONTENT="Yes"/> If the button had instead used "ONPICK=event" instead of "ONPICK=widgets" (above), then only the first line would have been sent. If that was the case, then the server could still request each value: <SCGUI@CLIENT REQUEST=Content FORMID=formpw WIDGETID=username /> <SCGUI@CLIENT REQUEST=Content FORMID=formpw WIDGETID=passw /> <SCGUI@CLIENT REQUEST=Content FORMID=formpw WIDGETID=keeper /> [end]
<scgui> <form id="form1" content="Login Screen Demo" visible="full" width=275 height=260> <widget type="label" id="label1" x=2 y=30 visible="full" content="Username:" /> <widget type="label" id="label2" x=2 y=60 visible="full" content="Password:" /> <widget type="label" id="label3" x=2 y=95 visible="full" content="Save Password:"/> <widget type="textbox" id="username" x=130 y=30 visible="full" content="Bob" /> <widget type="password" id="passw" x=130 y=60 visible="full" content="" /> <widget type="checkbox" id="keep" x=140 y=90 visible="full" content="yes"/> <widget type="button" id="cancel" x=40 y=140 visible="full" content="Cancel" onpick="event" /> <widget type="button" id="login" x=135 y=140 visible="full" content="Log In" onpick="widgets" /> </form> </scgui>Note that "form" may conflict or cause confusion with HTML's "form". Perhaps "SCGUIform" instead?
AsyncLevel = featureSupport("async") if AsyncLevel == 0 then [skip asynchronous commands] end ifThe level number can indicate different levels of support. For example, a Grid that allows certain columns to be "locked" for horizontal scrolling may return a level of "5", but one that does not may return only a level of "4". However, levels sometimes don't allow enough granularity. So feature names like "grid_lockable" may be needed instead. Note that lack of grid support altogether would also result in a zero for any grid-specific feature. I have not decided on an XML tag for feature querying yet.