Closed lrozema closed 9 years ago
I disagree about where this code belongs. As it's called ota it should be able to actually perform an ota update, not just write to the flash. Doing this replicates the functionality of libupgrade from the sdk for the standard bootloader. I accept it's not perfect, though I have never found a server that sends the header line by line (that's just inefficient design). I'd be happy to take patches to improve the code!
You are right. So maybe the none OTA specific parts from rboot-ota could be put in another file. Anyway I am receiving my OTA from an existing (non HTTP) stream so I like to use the rboot stuff but not the HTTP part. So when I am done abstracting maybe I will have a patch ready.
For the header parsing, the arrival of data has not necessarily to do with the application but is also influenced by the other network layers. For instance full TCP buffers, low MTUs, fragmentation, etc. all can result in headers arriving in parts. The callback could even fire halfway a line...
In rboot-ota/rboot-ota.c contains HTTP receive parsing code that IMO belongs to the rboot-sampleproject. I think rboot-ota/rboot-ota should only contain code that is about writing (chunked), switching roms, etc.. The actual download should be left to the user and should be in rboot-sampleproject.
Furthermore the HTTP response parser is very assumptious about how the data arrives, it expects the entire header to arrive all at once. But of course there is no guarantee this will happen. For instance when using SimpleHTTPServer from python all the header lines arrive one by one resulting in failed upgrades. But then again if this code is not part of rboot-ota anymore then it is not that big a deal as it is an exercise left to the user.