• Moar stuff as I continue to go through code...

    Errors and callbacks: in some cases there are "expected" errors, such as a bad password in a connect call. In those cases I think the best is to pass an err param to the callback which is null on success and an error string on failure. (This is what the current spec more or less has.) But there are also other errors, such as disabling the AP mode failing (not sure what would cause that, maybe if it wasn't enabled or the new default can't be saved to flash). In those cases I think it's best to raise an exception, just like we do if the user passes a callback argument that is not a function. Otherwise everything everywhere will have err returns and err arguments, and that just clutters stuff to be ignored in 99% of cases.

    Currently connect/disconnect/startAP/stopAP take an option that specifies whether the change is to be saved as boot-up default. I'm finding that this leads to lots of if statements, is not cleanly implementable on the esp8266, and I'm not sure it's all that great to use. In particular, this option kind'a suck on the connect() call because you have to commit to saving the setting before knowing whether the connection actually works. So if the user specifies a bad password and the new config is saved no-one is happy.

    I'm wondering whether a separate save call that saves "everything" to flash for the next boot-up would not be better. (I'd implement the saving in Espruino as opposed to relying on the SDK, I think.)

About

Avatar for tve @tve started