[Marble-devel] Kml Parser complexity

[Torsten Rahn]

Hi,

I had a quick look at it and it looks a bit easier to understand indeed. However 
I'm not still fully sure I got aware of all the technical consequences. What are 
the advantages / disadvantages (Speed, featureset, maintainability, etc.)?

So I suppose this would basically mean that you'd rewrite the parser? Or do you 
see an opportunity of doing an incremental refactoring? What is the migration 
plan? Any idea how much time it would cost and when you would do it? Would you 
do it in a branch or in trunk? How would the work affect the work of the GSoC 
students? :-)

So basically it would be nice to have a list of "pros" and "cons" on the 
technical level as well as on the project level.

Regards,
Torsten




On Thursday 27 May 2010 20:23:31 Bastian Holst wrote:
> Hi,
> 
> In my opinion the structure of our current KML-parser is too complex.
> Additionally I do not like the idea of casting around that often as it
> happens in our current KML parser.
> 
> If I understand and remember correctly a line like:
> return &parentItem.nodeAs<GeoDataRegion>()->lod();
> and the changing of these pointers attributes (as it is done later) will
> depend on GeoDataRegion::lod() returning the stored object itself and not a
> copy, but nobody can ensure that.
> 
> As a solution for that problem and to reduce the complexity of the parser,
> I'd like to change the structure to the structure which can be seen in the
> attachement.
> To my mind this doesn't reduce the flexibility of the parser, but makes it
> a lot more easier to understand.
> What do you think?
> 
> Note: The code in the attachement is just a quick draft and contains a lot
> of bugs ;).
> 
> Best regards
> Bastian