Add the WebSocket protocol to WE apps

WE no longer uses WebSockets. Yet it was an important feature of WE. Some of us chose Xojo because (among others) product using WebSocket.
WebSocket make our apps more responsive, faster. WebSocket is also more reliable because the events can be fired in order.

Feedback on WebSocket Feedback Case #27853
was closed by Xojo because it is not a bug, but a feature request.

Here is the new WebSocket feedback:

Feedback Case #28409

Please vote!

We already have a case for this. Our WebSocket implementation needs to be redesigned from the ground up, so it’s not a matter of just “turning it on”.

Hello,

There is a chance that the websockets are available in version 2014R1?
is highly anticipated.

Greetings
Olivier

Check feedback to see if any relevant reports are marked implemented and verified. My cursory search doesn’t find them.

I’ll go out on a limb and say “when they are ready” :slight_smile:

I’ll go further out on that limb and say No, it won’t be in 2014r1.

I have written an application that integrates a websocket capable server with Xojo. It is an open source project, the source code is available at https://github.com/v-control/V-Control_GPL.git The project page http://www.v-control.com

Cool. Although GPL is a non-starter. (EDIT: It’s questionably compatible with Xojo to begin with.)

Deja Vu?

Of course GPL is compatible with Xojo (in my opinion). The fact that my software is GPL and the source code is free don’t implied that the IDE has to be as well. The only drawback for people who want to use GPL code is that they have to respect GPL. I understand that this is a problem if you’re writing proprietary software. But anyway, I think the code is not that complicated or genius, so one can understand the code and write his own implementation.

I don’t believe Xojo is GPL compatible outside of just being a nice-to-look-at reference. GPL would require that the entire application (including Xojo libraries) be free software as well.

[quote=72996:@Dierk Walter]Of course GPL is compatible with Xojo (in my opinion). The fact that my software is GPL and the source code is free don’t implied that the IDE has to be as well. The only drawback for people who want to use GPL code is that they have to respect GPL. I understand that this is a problem if you’re writing proprietary software. But anyway, I think the code is not that complicated or genius, so one can understand the code and write his own implementation.
[/quote]

When a mutual customer asks me to be able to publish my source code to comply with your license, I’m going to have to strongly suggest that they break your license instead ;-). These infectious licenses are especially bad here because we don’t have a technical facility for even making something with Xojo source that might be LGPL safe.

OK, I think I started a discussion that should have it’s own thread, because it does not affect the original post. If you like to discuss this further I would like to be part of it. My opinion is based on the information provided by gnu.org.

[quote]Can I release a program under the GPL which I developed using non-free tools? (#NonFreeTools)

Which programs you used to edit the source code, or to compile it, or study it, or record it, usually makes no difference for issues concerning the licensing of that source code.

However, if you link non-free libraries with the source code, that would be an issue you need to deal with. It does not preclude releasing the source code under the GPL, but if the libraries don't fit under the “system library” exception, you should affix an explicit notice giving permission to link your program with them. The FAQ entry about using GPL-incompatible libraries provides more information about how to do that.[/quote]

The link to the original text is: https://www.gnu.org/licenses/gpl-faq.html#NonFreeTools

I’m not a native English speaker and non technical content is not easy for me to understand, but if I’m not wrong then there is no problem to develop GPL code with Xojo. Maybe a Xojo representative can give us his opinion?

if I remember correctly, a GPL license means that the person using your code also needs to release the full source code of their project as well if they wish to distribute it.

But GPL or not, this project does not help WE users. We would need to integrate the server portion of WebSockets into our framework for it to work properly.

Yes, thats right, I discussed that in a previous post.

It seems that I don’t understand the difference between Desktop and WebEdition. Yes, I wrote a desktop application that implements a web server WITH websocket support. There is an HTML/Javascript example Touch GUIs with WebSockets – V-Control that shows how to use it. I thought that the Xojo code could be used in WE as well. Sorry for the miss understanding.

Dierk do you have any Desktop Websocket Client that actually works ? The one in Examples folder is not working properly.

For me it works perfect. Did you change the IP Address in the example that it matches your server IP?

Absolutely.

The server normally knows when someone connects, sends messages and disconnects.

But if I connect (client side) using Xojo TCPSocket, Server doesn’t say that someone has just connected has he normally do.

Also, Server doesn’t process any messages but it however says that someone has disconnected (happens when you close the client Xojo app) so I presume there is some communication between them.

Probably the handshaking is failing or something, I don’t know.

As written above, I have implemented a websocker server with xojo. I do not have any client code. I use pure HTML / Javascrip as client.

Currently, the browser sends regularly a request to the server to see if there is anything to recover. It’s expensive. “502 bad gateway” errors also regularly appear in the browser console. (Even if it has no impact, it worries customers).

With WebSockets, the server can send a request to the browser without prior request from the browser. This is a big advantage. it would remove all these queries (and, I assume, threads and work on the server).

it would also allow us to make real push, inexpensive.

I also wonder if the xojo web app would less fragile.

Finally, is that this could increase the time when the application tolerates that there is no network (If there is no action on the browser and that the server has nothing to send)?
Currently the application (client side) falls if there is no connection for a few seconds.