Most of My Top Cases in Feedback are feature requests to improve Web Apps and their development. If any of these will help you, please consider adding your suggestions and some points to them.
If you have feature requests to improve Web Apps and want to promote them, please consider adding them to this conversation. Chances are that others may benefit from your suggestions but are not aware of the related Feedback cases.
For me, the server side is very important because we are dependent. Client side, if necessary, we can do differently: webSdk, librairies, handleUrl …
So I think it is important to review the operation of sockets and the communication with the browser, in order to increase capacity and reliability: websockets / http1.1 / http2, cache requests, increase the capacity and reliability of serverSocket , be perfectly compatible with the reverse proxy and load balancing (and documenting).
With handleUrl and specialHandleUrl we can do many things now with Xojo. But with these events, the handling of the database is not easy (unless you open and close the database on every request, which is expensive). It would take an object that works much like the session.
Maybe I’m misunderstanding something but I’m just using Session.Header(“X-Forwarded-For”) and Session.Header(“X-Forwarded-Proto”) to get those values when behind a proxy.
But honestly before they get around to adding new features I would love to see them fix all the broken things for WebApps. WebDialogs are a nightmare with sizing, resizing, embedding etc… there’s a handful of bugs related to various issues with this.
I must admit, built in load balancing would be the most amazing thing to happen. There’s currently too much overhead in this.
HTTP1.1 was documented there are more than 15 years. It significantly improves the protocol, it is a big update.
Xojo use 1.0.
A Feedback for http1.1 in Xojo was submitted in 2009.
Since 2012, the Feedback indicates “scheduled”
Meanwhile, websocket appeared. And now http2.
I have no obsession for http1.1, http2 or websocket, but these are big updates.
Another thing: I think I remember that with the new compiler, the Xojo applications will be significantly faster? it would be an asset to the WE server. Do not forget that the load balancing is effective but has a cost.
Using WebFileUploader? If so, my understanding is that there is no size limit for Stand Alone Web Apps and that CGI Web Apps are limited by the Web Server (Apache, etc.) being used.
Haven’t run into that issue yet so I’ve not looked for or created a relevant Feedback case. Perhaps you should and promote it here for others interested in signing on and maybe even throwing some points at it.
There will need to be fundamental changes in how our sockets work to give you this. As it is right now, even if we load the file in little chunks, we can write them to the socket’s buffer way faster than the socket can send them out. This means that your app must have access to enough memory to store the entire file in memory at the same time. Now technically, 64-bit will raise that threshold, but you’re still limited by physical ram on the server where your app is running… And before you say Virtual Memory, remember that we just read the file from disk. Using enough memory that things start getting paged to disk just makes everything slower.
My suggestion is still to serve large files using Apache, IIS or some other web server. If the content is static, put it on a CDN somewhere.
Yes, but if they are already in the browser cache, should be avoided to send requests. This is what I propose in this Feedback by changing the way of naming the files and changing the method of cache. Like this, as there is no update, the browser does not send these requests to each launch. The files are cached, there is no validation request (cache-control: max-age=15552000), and we can still update the files without problems by updating the name.
So here’s the thing. What we do right now is we set the modification date of the framework.js and styles.css file to match the app itself. This is because if you build a new version of the app and youve added a Control that you hadn’t used before, these two files are now different than they were before. The browsers still request the file, but we check the modification date and respond with a Not Modified when it’s appropriate. We respond the same way for all of the rest of the files you listed there as well.
This seems like a pretty basic problem for a web server. Please fix this one. It’s my top request.
<https://xojo.com/issue/37770>
Also fixing the SSL bug that I reported ages ago would be nice. I still have software I’m not updating/releasing because of this one.
<https://xojo.com/issue/31800>
Yes, it is good already. But there are still 7 requests that are sent, and the response is expected. Even if they only return a 304 response, mobiles are little of simultaneous requests and the mobile network is not always responsive. Meanwhile, we could send other requests to load our js libraries, web font files, etc.
