Theres nothing that prevents you from creating your own HTTP server for your special needs.
While that’s true, it’s harder to maintain different projects. And currently the App.HandleURL does provide “some” functionality but it’s incomplete, we can’t keep a connection alive, we can’t flush “partial” data. It seems to be threaded but unable to “flush” so keeping alive is not possible currently. Therfore the whole http1.1 spec can’t be implemented making it not very practical. Reconnecting for realtime data over http is alot of overhead.
There is no need for Xojo to expose the whole http/1.1 spec. There IS a need for a Xojo user to be able to do so.
First of all, we never said that HTTP/2.0 would be part of the Web 2.0 package. To do so would require a huge refactoring over what weve already done and we were not prepared to delay the product any more for the unproven improvements we would get. If, as you say, there is much more competition to this available, and our web framework doesnt suit your needs, my suggestion is to use what works best for you and your product.[/quote]
I didn’t said http/2.0 will be in there but it PROVIDES alot of very usefull features (priority, concurrency etc.) in the spec. So if we’re able to use that, then it would be a big plus as it’s HTTP/1.1 backwards compatible and we won’t be behind the hurdle again.
Look around in the forums, see how many people talk about “API” (REST API’s) and creating them. Having this as a complete possibility in XOJO would get more attention to XOJO itself. As it’s easy to use xojo and create micro-services and such. It’s scalable (especially having a stand-alone webserver) and extendible.
Currently we are stuck with very limited possibilities or “create your own” but then using open-source alternatives is easier and provides more possibilities. We DONT want to go to other tools, we want code-reusability.
It’s not that Xojo isn’t going the way we ask as App.HandleURL came by FB request and it did help alot. Just having “a little more”* to it would mean we can move along with the “tech” currently still in use.
*allowing a developer to start a web app project and implement App.HandleURL and keep the connection open (closing when the event returns or sets a close flag. I don’t think this is too much to ask?