Lost in Translation

So having gotten back to work after the New Year, a tip to India and a touch of lurgy, things seem to have been happening! The googlesky problem I was faced with seems to have magically been solved using Google AppEngine. My python code, instead of instantiating a web page and calling methods within, is now delivered in javascript, which then calls python from the javascript handler. I think avoiding javascript is no longer a choice now and I'm going to have to face learning yet another programming language for this specific project else I'm going to be fairly lost in translation.

In the meantime, I've been ploughing through the C4 algorithm and I think I'm happy with what the component parts do in terms of input and output. I still need to figure out what's actually going on inside the subroutines though, especially the count and testcount functions. They have a lot more going on than I initially thought. And the net output of the program is still gibberish to me. I need to see if I can come up with some sensible output. Or maybe find some standardized naming of the actual variables. I'll look up the NVO to see if they have anything useful I can call on later. Still haven't geared it up for dynamic array setting... the problem is when I have to deal with an observing footprint, specifically the DES observing footprint, I'm going to get a lot of junk from the testcount function. I'll have to dig a bit more and see if this is something that's previously been solved or whether I'm going to have to start from scratch. If I do have to start from scratch, I think I'll try and use the SQL syntax used in the NVO. This might mean extra work having a C++ parser for an SQL query... a risk of being lost in translation all over again. I think perhaps a lookup table might be the fastest/easiest way to do this.