Marble is a nice 3D(ish) globe program that is part of the KDE project. It is mostly built on Qt so it is easily portable to any platform. What i set out yesterday to do was the relatively simple task, or so i thought, of understanding the XML parsing system of marble with the intention to implement a simple test implementation of a Open Street Map parser. When i started yesterday i was full of vigor and looking forward to the challenge, but by the end of the day i was sent home with my tail between my legs.
So you might be wondering what can scare a young programmer so much... Its all just a matter of understanding. The little bit of programming that i have done for marble 2 years ago consisted of a simple (naive) XML parser that read in GPX information and rendered it to the screen, but since then the XML story of marble has become a lot crazier. Not long after my time in marble a unknown programmer ( unknown to me, please post their name in the comments if you know ) came on board with a solution, and because of his work on the Webkit engine you can bet that he knows what he was talking about. The problem with his solution was simple, it was "Right".
Yes that's right, you heard me! I'm complaining that a solution is right and i have good reason! My goal yesterday was to understand the XML implementation in marble, i understood the concept in about 5 mins but the implementation was littered with so many "Best Practices" and "Time saving Tips" that i challenge anyone who hasn't spent some time doing production level XML parsing to try and understand it and implement a parser in less than a week! This kind of a system is so intimidating to any programmer that would consider having a pet project using Marble's Parser would be instantly scared off. I'm not saying that we should sacrifice all performance for "Ease of use" but i really believe in a balance, one that will be inviting to new programmers but still encourage them to learn some of the "Best" ways of doing something.
I'm not going to get into the details of what i really didn't like about the parser but i will list a few points.
- Macros! god i hate macros, and i would put that down to being thought in my first year of programming "Don't ever use Macros, they are Evil". I wouldn't necessarily say that they are evil but using them to save time really feels like a bad idea to me, a more structured architectural model may result in less use of macros? who knows!
- Element dictionary! Ok this sounds like a good idea in theory, and i can see where this can be a very good idea in practice too, but i really don't think that a standard parser that uses an element dictionary is the "Best" way to account for the many varying formats that could represent data that a marble module or plug-in might be interested in.
- Parser only able to return GeoData! one problem with using this approach with OSM is the xml tags do not completely enclose the relevant data in their children or parents. To actually implement an OSM parser you would need to modify the parser itself, which doesn't really make it a generic "One size fits all" parser.
I have proposed a solution for a middle ground to the head developer already, we have discussed it at length and i will be doing an experimental solution based on what we discussed to see what it's performance is like.
I might be convinced, at some later stage, that the parser model in marble is in fact the best solution for Everything! but just not right now!
Till next time,
Over and out