ESP8266 Community Forum

- Fri Mar 23, 2018 10:45 am #74852 Thanks. That is exactly what I was planning to try but did not yet get to.

- Fri Mar 23, 2018 7:49 pm #74866 I have avoided AJAX in favor of websockets, but there are situations where AJAX would be preferred. I'm not sure if I will use this but I do like what you have done. Good examples.

I think you should have called it AJAXemb. It would be easier to find in the example list or to find the correct directory in the library. But this is such a minor thing.

- Sat Mar 24, 2018 3:49 am #74869 AJAX vs WebSockets: Well, I suppose I put "AJAX" in the name, but actually my idea is that the "how" of data transfer is an implementation detail. Something that the user should not have to worry about. And in fact, most of the code in EmbAJAX itself is "unaware" of how data is being transmitted. So actually that would not even be a design decision that is set in stone for all times to come.

I would also maintain that essentially the same things can be done in AJAX and WebSockets, although, clearly, some things can be done more easily in one, rather than the other. On the side of "easy with AJAX", what i cared about was:

Easier to cope with unreliable connections: Since there is no persistent connection, each request can be handled independently, and state tracking comes down to a single number "what is the number of the latest change this client has seen" (the client tells us in each request). A client goes out of range, then back into range a few minutes later: No problem at all.

No arbitrary limit on the number of clients that can connect. As EmbAJAX does not need to keep track of clients at all, the only limit is processing power (or network bandwidth). And don't just think multiple clients, also think multiple pages served from the same device!

Now WebSockets would primarily promise lower latency in two cases:

a) When sending data from client to server, due to slightly lower network overhead. Undeniably true in theory, but I simply don't see that issue in practice.

b) when sending data from server to client. Undeniably so, as the AJAX solution has to rely on polling in this case (not when the data sent back is in direct response to a user input from the client, but when sending "spontaneous" events from the server). Right now the polling interval is hard-coded at 1 second in EmbAJAX. On the other hand, also with WebSockets, there is the question of just how fast the server can and should send status updates. You probably do not want to send a new sensor reading over the network on each iteration of loop(). So while the advantage clearly goes to WebSockets on this count, this does not immediately translate to a real world advantage in many use cases. My idea here, is rather, that if you have a real use case for low latency spontaneous event delivery from the server, EmbAJAX will not help you there. But also, by not clogging up permanent connection slots, it also won't get into the way of combining it with a dedicated WebSocket connected custom control.

So that's why I went with AJAX over WebSockets. But to be quite honest, I'll have to admit I'm also notoriously old-school, and always lagging behind the current hype in technology by several years. I guess that may have played a role, too .

- Sat Mar 24, 2018 7:46 am #74876

I have avoided AJAX in favor of websockets, but there are situations where AJAX would be preferred.

As I had said, and you listed, some of the very reasons. Another one I had read about, but up until now is not an issue for me, is that very locked down secure networks that we don't have control over may not allow websockets.

but actually my idea is that the "how" of data transfer is an implementation detail. Something that the user should not have to worry about

I totally agree. I wished that this library was available a couple of years ago when I was trying to understand all this. And whether or not someone uses this library I think they certainly can learn lots from it.