GPS Module, Extensions for handling other sentences, and u-blox NEO-6M GPS receiver

Thanks for sinking your already scarce time resource into this. I'm sure you would like to have satellite brains and body clones working for you and executing all the creative ideas going on in your master brain... ;) - something like this happens in my dreams. Back to - nevertheless - exciting reality:

covered the question of memory usage in the other post...

Gives me enough food for thought to take the next step in adjusting into the architecture and spirit of Espruino as a whole. I'm sure the two links in the addendum post will explain the term root scope. I will resume with the memory conversation when resuming with the related project, which is: http://forum.espruino.com/conversations/127039 - Exploring 2.8" Color TFT Touch LCD by PacMan Game attempt.

What I'm thinking about you suggested 'new' implementation of GPS module - well: I'm going back to school is for sure part of it... other parts are:

I began with list of thoughts below... until paying closer attention to '.start()' method... and got stuck in it.... which toppled almost everything but the first thought to the point of actually being wrong... and to being wrong about code 'annihilates' - or at least - questions most of my (professional) past... therefore: Disregard the list. I will come back, re-think/buke and re-write the list. For now I can say that I 'see' great progress. ;). To have an idea where this all is heading for, take a look at the running application of the GPS module at http://forum.espruino.com/conversations/255759 - DIY Marine GPS using enhanced GPS Module, u-blox NEO-6M GPS receiver, and ILI9341 Module controlled 2.8" Color TFT LCD.

1. Comparison with my code / solution patterns highlights the suggested form of writing modules
   
2. Having .start() and .stop() methods and their way of implementation great in many ways - and with it - the whole module passes object-orientation with flying colors. It now allows also to have multiple GPSs... ;) - which I was thinking about in the previous solution, but considered it a rare option... I'd rather have two complete systems connected to a network for 'high'-availability.
   
3. The .stop() 'disconnects' the handlers completely vs. the approach I chose. I was thinking about something like that but had not studied Serial object enough yet. My solution comforted me by the fact that it keeps up with 'complete' lines in the background makes a resume flawless... which I guess is not the case with suggested .start()/.stop()............................ ooooops.................. see comment in italics above this list.