-
I am making a REST request to an HTTP server and sending a GET request to it. This is sending a response but at the end of the response, I am not seeing a
response.on("close", ...)
being called. My suspicion is that the server is not closing its end of the HTTP socket. Does the Espruino implementation look at the HTTP response and its Content-Length and then close the client socket or does it expect the server to close the socket? -
Howdy ... have a look at this video and see if it matches close to what you tried ... see:
https://www.youtube.com/watch?v=aJj4WJzAo4w
You shouldn't be flashing any JavaScript (at least not that I am aware off) ... rather you should be attaching the Web IDE and entering JavaScript there.
There is a quite active live chat on Espruino (and Espruino on ESP8266) here https://gitter.im/espruino/Espruino where there may be folks who can assist live.
-
What I'm trying to do is "play" end user. So I go to the API docs for
httpSRq
and found theread
function.http://www.espruino.com/Reference#l_httpSRq_read
The few words here say that when
read
is called it returns the characters that have been received but not yet consumed.Then I pair that with the
close
function ... which is a callback event called when the partner has closed the connection. My assumption was that the data received but not yet consumed could be consumed at that time.I am sensing that this is not a valid assumption ... and if that is the case, what I'd like to do is document that consideration so that future travelers won't be led down this path.
-
In this puzzle, my goal is to issue an HTTP GET request and when the complete response has arrived, process it.
Looking at the APIs, I see:
http.get(options, function(response) { // handle response here });
In the response handler, I am given an object of type
httpCRs
(I believe). However, if I try and print:response.available()
I am returned a value of 0. I figured that was ok, because at this point, in execution, data had not yet arrived and there was indeed none available.
So I figured that I could code up the following:
response.on("close", function() { print("Available = " + response.available()); });
However something seems to be wrong here. The "close" event function is not being called. By sheer luck, I found that if I coded:
response.on("data", function() { print("We have received some data"); }); response.on("close", function() { print("Available = " + response.available()); });
I then find that the code event callback is being invoked ... but of course, I have consumed my data.
So it seems that if I code a
response.on("close"...)
without aresponse.on("data"...)
the close callback is not being invoked.Am I missing a concept here?
-
Thank you @allObjects ... that is perfect. Time for me to study in depth all the different features of the IDE. Appreciate your response.
-
-
@MichaelPralow ... I was reading your post and a thought struck me. Given the fact that the AT command processor running on ESP8266s is no more and no less than a relatively simple app that reads data from the serial port and writes responses to the serial port and has chosen AT commands for the purpose ... would there be any interest in an alternative app that accepted as input and returned as output ... JSON strings?
If such a thing existed, then I am guessing it would easier for a native Espruino board to send and receive data as we would no longer have to have this vague intermediate format which is the AT command set?
-
Howdy @hygy. See issue #661. (https://github.com/espruino/Espruino/issues/661). Any thoughts and comments in that issue are very welcome.
-
At the start of the
Reference
page there is a detailed list of all the boards that Espruino is believed to work upon... see:http://www.espruino.com/Reference
My vote for board specific details and caveats would be in the board specific page.
There is a work item to create a page for the ESP8266 ... see issue 653. I had assumed that these pages were no more than simple web pages (say written in markdown or HTML) but it seems that they are (to some degree) generated pages and this means that the page for the ESP8266 is not a trivial matter. Rather than have to study the board specific page generation architecture myself, I was hoping that someone in our community could step up and own that as a distinct task and either create a detailed recipe that would be easy to follow or act as a resource for each board creation team and own the creation of the initial version of the page for each team.
-
-
<opinion>
My vote would be internal docs on how to Espruino works internally remain in the Wiki ... and design docs about the internals of a specific board would be included there. User guides and documents specific for a consumer of Espruino should (of course) make it into the espruino.com web site.
</opinion>
-
Howdy Duane,
For raw ESP8266 questions, let me invite you to the ESP8266 community found here ...There you will find a metric ton of goodness on ESP8266 including all the questions and answers you could sensibly want ... including a great bunch of responders who try and assist all levels of users with complex and simple questions.
-
I tried it on two separate PCs and got the same result ... it is still very possible that there is something screwy in my Chrome settings ... especially since all my chromes are "linked" ... and I did an "un-install" of an old version first ... but I'd hate to think there was somehow a bad build out there and I didn't report it.
-
-
-
-
@sameh.hady You ROCK!! I can't wait to try this out.
-
@Gordon ... personally, I'm a big fan of books in PDF format ... so yes to a book. I believe you like the notion of the documentation of a product to be self generating but my own opinion and experiences point in the other direction which is to have a separate book that is kept in sync manually. I would also suggest that any such book be "one file" (eg. an open document
.odt
file). That way there can be easy cross reference and searching and linking and such. -
I read the docs on
E.on('init')
here http://www.espruino.com/Reference#l_E_init and I'm not getting "it". If I write a JavaScript, surely the script runs at line 1 onwards and hence if I wanted initialization functions, I would explicitly execute them from my script?Now, if I was to "guess" what is going on, what we are saying here is that
E.on('init')
causes functions to be registered which are saved in the "state" when a JavaScript program is saved to flash and are run when it is load from flash? Is that close to being correct?If so, I think we need a page of documentation (if it doesn't already exist) that describes the philosophy of save and load of programs and the state that is maintained. This would then want to be referenced in the docs for
E.on('init')
. -
Since the merge a week when the work @blaz had started was merged into the single Espruino github repository, everything I have been working on since that time has been against an issue (see https://github.com/espruino/Espruino/issues) and when worked upon to a state where it was unit tested and (to the best of my ability) not regressed anything, a pull request was issued against the master waiting for @Gordon to approve and issue a merge. Because I am now working against the Espruino master repository, I have benefited by being able to pull the latest work performed by others and also pushed into the repository.
I'd suggest that what you probably want to do is create an issue for each area you have addressed, merge the code changes for each issue (one at a time) ... and created as many issue specific pull requests as needed. There may already be issues that already exist that you might want to look at to do work against. For example, there is an issue for getting GPIO settings right, an issue for getting the new code formatting correct and others.
I also recommend creating issues even if you aren't ready to work on them immediately. A lot of the issues have notes and comments and design proposals already in them.
-
The "Connect over TCP address" is present in the downloaded Google App and seems to work great when connected to a Telnet server. I am now looking to @Gordon for some quick answers to some questions I have to get that enabled in the ESP8266 port ... but it looks like it is all going to come together nicely.
I'll do a low level sniff of the HTTP protocols and see what is being sent back wards and forwards and that will prime the conversation better.
However, do we have the correct semantics just now? Here is my thinking ...
We send a HTTP GET request ...
We get back an HTTP response ...
The response is composed of:
[Header]
[Body]
The [Header] contains "Content-Length" which is the size in bytes of the body.
We call
on("data")
with each piece of the body received.However ... if the server should NOT close the socket connection, then the JS app will not know that it has received a complete response. There is no "bracket" callback that says that the data received up to this point constitutes a single record response.
We might wish to capture this somewhere in documentation if these are the semantics we want to stick with.