On Thu, 4 Dec 2003, MenTaLguY wrote:
On Wed, 2003-12-03 at 05:32, Ian Grant wrote:
I was imagining the interface would be just that provided by gdome2 plus functions for rendering specified regions at specified scales.
This is obviously not what Mental is planning ... I presume there are good reasons why - it's just that they elude me :-)
Replacing the XML tree architecture that we inherited from Sodipodi with GDome would be a pretty major architectural change (it could substantially touch nearly every file in the tree).
I'm not, on principle, opposed to using GDome, but I don't think it would be a good fit for us as the core XML representation.
The SPRepr architecture has some very rough areas, but it is very resource-efficient and has some nice properties (it's essentially a hierarchical database, with transactions, among other things).
I'll ditto the remarks. The repr system seems pretty solid, the one major missing piece being documentation. It's not clear what functions need to be called to do what actions. It looks like this system is kind of the heart of the application, so documenting its API would probably make work easier in a *bunch* of different areas.
I think where DOM is required long-term we'd be better served by implementing DOM atop our own tree representation instead. The DOM interface, at least as specified, is indepentant of any particular implementation (less true of the non-standard C bindings, but...).
-mental