The websocket framework needs an overhaul, because the version that was implemented the first time was not based on the working draft which became the final released spec. It’s still in the list.
No timeframe on it? I knew it didnt work in 2011r3 (that i had before Xojo) but thought it worked in RS2012rX. Il’l just have to put my waiting hat on I guess 
@Greg Olone : it’s very important to have some “visibility” on your plans about WebSockets implementation as it appears to be a solution for better performance.
I’ve now dived into WebControl SDK. It’s very interesting to “include” external web controls but the integration with the framework is very limited (impossible to use styles, visible, enabled etc…, object heritage…)
Of course, I can miss something important or mission in the documentation…
We don’t speculate about plans because every time we have in the past, either it’s not fast enough, or the schedule slips for one reason or another and then users are mad at us.
You absolutely CAN use styles, properties like visible, enabled, etc… you just need to do it set it up yourself. Like the desktop plugin SDK, we presume nothing about your control. …And by the way, as far as I know, WebSDK object heritage does work in 2013r1.
I was wrong about Web Control SDK, I’ve just discover the FrameworkPropertyChange that helps a lot to integrate.
But I still have problems with heritage… I’ll work deeper on it.
@Greg Olone : I understand that giving a delay is difficult, but this feature is documented as working.
I had to spend a lot of time to figure out that what was written in the doc was false and that the web sockets were just desactivated in the framework source.
It’s not like if it was a roadmap feature !
Yes. And it’s been a long time that this feature is disabled, I think.
That said, when it was on, I did not feel there was much difference between the browsers using the websocket and those who did not use it. But I was starting with WE. Perhaps some had been testing Websockets performance?
The websockets are also important for mobile / tablets, slower than computers.
Web sockets made a noticeable difference in responsiveness. (Note: CGI builds could not use them.)
[quote=18028:@olivier vidal]That said, when it was on, I did not feel there was much difference between the browsers using the websocket and those who did not use it. But I was starting with WE. Perhaps some had been testing Websockets performance?
[/quote]
You lose all the overhead of getting a new connection for each event. That could easily cut traffic by 80% for some apps. But most important, the events would arrive in order. Take a day to try to make a simple layout change for portrait/landscape in a WebKit mobile browser work reliably and you’ll see what I mean. Hint: no fair effectively defining a event that sends window size and orientation back to the server.
If we ignore the bugs and improvements not absolutely necessary, I think the most important requirements are:
- Reliability of the session management (done?)
- Reliability of the order of events, rapid communications with the browser: WebSockets
I add three:
-
Better support of the reverse proxy. I think it is important in business environments.
-
HTTPS for standalone applications (pending better support for reverse proxy)
-
More browser Controls. Daniel Taylor (http://webcustomcontrols.com/) and Brad (http://www.studiostable.com/webessentials) have done a great job already. But there are other needs, especially for tablets and smartphones. For example, a chart control, compatible with mobile devices, as HighCharts (http://www.highcharts.com/products/highcharts), would be welcome.
Controls like Highcharts improve the attractiveness of our applications. They also reduce the bandwidth requirements. I like ChartDirector, but it is aging and we need to do much work as possible on the client browser, to reduce the load on the server.
I hope the WebSDK facilitates the work, and we will have controls like Highcharts. A compatible mobile text editor, would be very useful! But I feel that it is difficult to find an IOS and Android compatible editor. I saw some like http://createjs.org/ http://xing.github.io/wysihtml5/ http://imperavi.com/redactor/ http://jejacks0n.github.io/mercury/, but not work well either IOS or Android.
Generally, the biggest weakness of Xojo, I think, is the lack of integration of the database. We lose a lot of time in the SQL processing. Integrated tools (as Wakanda) are much more productive for business applications. I think Xojo can improve in this area.
Fwiw, we don’t even guarantee the order of events on the desktop. There are two challenges in this area:
- The different browsers fire events in a different order from one another
- The general nature of the Internet means that two requests leaving the browser at the same time may not reach the server in the same order as when they left. Websockets help with this, but
- WebSockets only work for direct connections, I.e. Standalone deployments.
I am a little curious as to what you mean by “lack of integration of the database.”
Just did a quick lookup of Wakanda. Keep in mind that this is a JavaScript library. Without translating your Xojo code to JavaScript, there’s a lot more back and forth required to do the same thing. That being said, we are always looking for ways to optimize that process.
Thank you Greg.
on the database, there are tools such as 4D or Wakanda, the database is the heart of the product.
For a long time I have not used 4D, but from what I remember:
-
There is no need to check for errors on every request.
-
The SQL language is part of the product language, not a string. This allows a lot of flexibility, fewer errors and faster input (predictive text)
-
In addition to SQL, we can query the database quickly and easily directly from the language of the product. As these examples http://www.wakanda.org/dev-center/examples-code :
[quote]- var emp = ds.Employee(5); // find an employee by the primary key 5
-
var collection = ds.Employee.query(“salary > 50000”);
// find the list of employees who earn more than $50,000 -
var emp = ds.Employee({lastname: “Smith”, firstname: “John”});
emp.salary = emp.salary * 1.1;
// increase by 10% the salary of John Smith
emp.save();[/quote] -
In general, the data are closely associated with controls. For example, we can have a query that generates a million lines and feeding directly webListbox. So that the control is reactive, the server will only send data to display. When the user scrolls the listbox data, the server will automatically send the new data to display.
(Sorry for my bad english)
ok, thank you Greg, our comments crossed paths.
[quote]Websockets help with this, but
WebSockets only work for direct connections, I.e. Standalone deployments.[/quote]
This is, among other things, why the solution “Standalone + Reverse proxy” seems more effective. It is fast and flexible.
I do like how interactive libraries like Highcharts makes the graphs, but until they come up with 3D surface maps, I’ll stick with Chart Director. Honestly, though, I wouldn’t consider CD dated. They’re still great looking, highly customizable charts, and Christian did release an example that provides some interaction in WE.
Thank you Jason. I agree, Christian has done a very good job, as usual. 
But I think we should gradually focus on browser technology for this type of thing.
Another example. I have not tested this, but from what I understand, the widgets can be dynamically linked to the database.
For example, you have a webPage. On the left, a list of customers. On the right, widgets on the selected client: list of invoices, photos, sales charts, etc.
If the user selects a new client in the list, the widgets will be automatically updated: chart updated automatically, etc… Very little code.
Agreed. What I’d really like to see is more javascript libraries (e.g. jquery, dojo, etc.) incorporated via the WebControl SDK. This would probably be a worthy community effort on GitHub…
[quote=21553:@olivier vidal]- Better support of the reverse proxy. I think it is important in business environments.
- HTTPS for standalone applications (pending better support for reverse proxy)[/quote]
Both are important for our web apps but the latter even more so. My understanding is that the latter is dependent on significant improvements to the SocketCore, TCPSocket and SSLSocket classes. If so, both our web and desktop apps would benefit.
+1 for more attention to these aspects of the framework
Feedback on WebSocket <https://xojo.com/issue/27853>
was closed by Xojo because it is not a bug, but a feature request.
Here is the new WebSocket feedback:
<https://xojo.com/issue/28409>
Please vote!