GXml and the End of Summer

Silly mistakes in namespacing



Stupid mistakes!  I made some bad assumptions about how libxml2 handled namespaces (perhaps I could patch its documentation to be clearer?) that led me to mis-implement namespace support in GXml.  Of course, this was discovered while trying to understand the results I was getting from libgdata's test suites.  Hooray for testing the library by porting a real user of XML!



Sometimes I used namespace definitions instead of the namespace on an element itself, and didn't have a way to separately access them.  At first I thought I had just failed to assign something somewhere, and I spent too much time with gdb and print statements before I realised my mistake was more fundamental.  Oops.



I committed and pushed the changes and updated my test case last night.  There are also more internal classes of NodeList, mwahaha.  Now that the namespace support should be right, I can should finally be able to submit my patchset for libgdata.  After more testing today.  Mwahaha.



Google Summer of Code



The end is nigh!  By the 22nd, there'll be a new release you can play with.  API stability won't be quite guaranteed until I've ported a few more users, though.  GXml development is randomly projected to continue until 2018.  The format of my blogging about it will change, but you'll still be able to enjoy interesting progress (instead of weekly reports) here.  Bring popcorn.

GXml and the Amazing Desktop Summit!

(whoops, this was posted last week, but I failed to tag it correctly to appear on Planet GNOME.)  



The week previous was divided between a school assignment and finalising arrangements to fly from Guelph, Canada to Berlin, Germany for the 2011 Desktop Summit.  Since arriving for the summit last Thursday, I've been able to meet my awesome mentor, Alberto Ruiz, in person, and sort out the remaining two weeks of GSoC



Desktop Summit 2011



This is an amazing experience.  I'm still incredibly grateful for the GNOME Foundation's sponsorship.

I will write more nearer the end of the month about it, but for now I'll just say that it is amazing to meet developers I've followed on Planet GNOME for so long.  I can now testify that GNOME developers (including Google Summer of Code students) are a special and amazing breed of people.  I am also glad to say that about KDE developers, and hope that joint Desktop Summits continue in the future.  There were quite a few excellent talks, and the collaborative and productive atmosphere is invigorating.



Also, hackergotchies are not the best way to identify people in person. :)



Remaining plans for GXml

• namespace support: it's going to be read-only for users of GXml right now.  There are API complications when you allow people to create nodes and attributes with and without namespaces in the same document, and it's unclear how we should handle that.  However, if you parse an existing document, we support accessing the namespace information that the underlying libxml2 parser parses.  Our original goal was to implement DOM Level 1 Core's API, and namespace support isn't part of it, but is necessary for many GNOME users of XML.  Oh wait, I just pushed this last night! :D  It is now in git.  It was blocked a little by a bug involving syncing GXml Attrs and
  libxml2 attrs (the bug being that I had forgot to finish implementing that earlier
  :O), but that has been solved inelegantly for now.


• libgdata: with the advent of read-only namespace support (as of last night!), I can now finish the patch for libgdata to GXml.  I will be reviewing my patch and splitting it up for Philip Withnall's sanity.  Ha!


• API examples: I'm going to provide a few example files on how to use GXml from C and JavaScript. 


• bindings: my mentor has indicated that the build system we're using (WAF, not autotools!) has imminent support for handling my binding generation, so hopefully that will become available before the end of my GSoC.  It may delay examples for JavaScript, but C is working well already (see libgdata support :D)


• gtk-doc: we already provide valadoc documentation, so I'll worry about gtk-doc until shortly after the summer.


• live.gnome.org: I want to update thi-oh, there, I just did it.


• NamedNodeMap: right now we return a HashTable of attributes to users, but this is annoying because we can't see what changes they make to the attributes unless we keep a ref to the table and check it before we need to resynchronise the HashTable we gave a user and the local list of attributes for a given element. This means I will probably implement NamedNodeMap from the spec by wrapping a HashTable (or, if we end up using libgee, extend its HashMap) to update our libxml2 list of attributes on an element as the NamedNodeMap gets altered (attributes added, removed from an element).


• everything: so, after talking to a variety of developers including my mentor Alberto, Michael Meeks, Shaun McCance, Philip Withnall, and many others, GXml will attempt to add everything ever, and it will be awesome!  We'll probably start with more complete namespace support, then SAX parsing, then XPath, and then I'll implement the much desired and maligned XPath2 and XQuery, and then we'll optimise GXml to make it superefficient, and then implement a tea brewing API.  Mwahaha.  I'm very grateful for all the good feedback and interest I've gotten at the summit, and encourage anyone with an opinion on the future of GXml and XML in GNOME in general, to please let me know! (aquarichy AT gmail DOT com, or in the comments!)  Or, if you're at the summit and you see me walking around, poke me!

 Cheerio!

GXml and the end of July: an update

This past week has been spent doing

• Desktop Summit preparations!  This actually consumed most of my Friday, even, and while it's not strictly part of GSoC, I am hoping attending the Desktop Summit will benefit GXml. :)


• Polishing code, including the Document class and DocumentFragment.  DocumentFragment through libxml2 didn't behave exactly as I had hoped, so I had to add more local logic in GXml.  I've tried to keep the amount of local logic to a minimum, but that has sometimes involved rewriting chunks of code or redesigning a few things, which can take more time than just writing the DOM Level 1Core's functionality myself.


• NodeList support.  NodeList is iterable and supports methods from GLib.List, but does not subclass GLib.List, since depending on the usage, it is sometimes backed by libxml2's nodes' linked list.  One of my favourite features that I worked on this past week which took a little bit of planning and prototyping was having a live NodeList for get_elements_by_tag_name ().  By "live", we mean that if you obtain a NodeList of descendant elements from element A with tag name B, if you later add a new descendant to A with the tag name B, it should be present in the earlier-obtained NodeList.  This now involves each element maintaining a list of such NodeLists that have been requested at that element, and addition and removal of nodes to an element now notify its ancestors which check whether they're watching a NodeList for the new/old element's tag name.  If so, they update the NodeList.  Despite being happy to have implemented it, as its an API I used in other DOM implementations, I'm considering disabling this functionality by default, because I can imagine it being expensive when you're not actually using get_elements_by_tag_name () but have many insertions or deletions to do via the DOM, and letting users enable it at the Document level.  Or enabled by default with an option to disable.  We'll see.


• Namespace support investigation.  Support for namespaces exists in DOM Level 2 Core, but I believe it would require too much work beyond the scope of this GSoC right now to implement all the namespace-related changes from DOM Level 2 Core.  I looked at libgdata to try to understand just where and for what it required namespace support, so perhaps I can implement a subset now at the Document level, and worry about it at the Element and Attr level later.  That's going to be a focus of this week, as well as polishing the libgdata patch so I can give it to Philip Withnall for comments.

I'll be making my way from Guelph, Ontario to Berlin, Germany over part of  Wednesday and Thursday this week, so my next update might be longer or shorter depending on how well I can work on planes and trains!