It feels good to be making progress. It is also a relief. When I first started, I have to admit that I had a little anxiety at the thought of accomplishing a "real," bigger contribution during the internship. The GNOME Keysign codebase isn't particularly large, but there are enough files to get lost. Recently, in an interview someone asked me to give an example of a design decision. Considering how important readability is to maintaining code, my initial perspective is that the logging has been invaluable. Python is fairly easy to read, but the logs helped me track the flow of data. If it wasn't for the logging, it would of taken me a lot longer to figure out the code base. After working with the logs and adding my own piece of functionality, I feel a lot more nimble within the source code. That is to say, I have a better idea where to look for something when searching for a piece of functionality. Yet, if I look back over the last week or so, it seems like another thing that really helped to get started was to just dive in and start messing with the code, even if it was just adding more print statements. It was at this point where I started making more and more progress each day, which is clearly reflected in my github commits.
Another challenge to the project, is the number of subfields that I will work with over the period of the internship. My first task involved working with Avahi browser. I didn't know anything about networking, which I thought would be a barrier. However, I guess that's what information hiding is; you don't really need to know the implementation of something to use it. Anyway, something to keep in mind when I come up against another unfamiliar concept.
On to the implementation. I left off with the server announcing the fingerprint in a readable format. I thought the solution would involve rejecting the server and not adding their information to the list of discovered services. However, the better implementation was to transfer the data to the GetKeySection where I filtered out all the published data that did not contain a matching key. After reviewing this version, Tobi suggested that instead of filtering the list of server data, that we should sort the published data by matching keys. If there is a matching key on the list, it will be sorted so that it is the first entry which will result in the application only downloading the information for that key. What we have is that if the key is not present in the list, then the program will download all information from all services discovered. I struggled a bit with why this was a preferable method until Tobi mentioned backwards compatibility. If someone has the old version of GNOME Keysign that does not announce a key, then the second version will not download the information even if it is the correct key. Thus, this is another reason why my original idea of not adding the service if it did not have a relevant key was not as sound as I had thought. It too would not maintain backwards compatibility. After a few more revisions to bring the code up to standard, everything is set and ready to merge.
As a side to this story, having my code merged is a very satisfying feeling, especially in the realm of open source. Some cynics may doubt me, but it gives me a genuine warm fuzzy feeling. :-)