Hi Richard and others! On Fri, Aug 16, 2013 at 5:54 AM, Richard Schwarting <aquarichy gmail com> wrote:
Daniel's right that we'd love to have XmlTextReader and XmlTextWriter wrapped in GXml; it's on the list of things to do, along with XPath and SAX. If you'd like to merge your work eventually, feel free to use a branch in the gxml repo. :) I like your idea for XmlReader as a proxy class.
I'm glad to hear this! I don't have an account at git.gnome.org, but have been pushing to a gitorious repo. I now rebased this (manually with git diff, I can't quite figure out how to use git rebase) on top of the gsoc2013 branch with one big commit that I also append to this mail as a patch. The commit message has a brief summary of the changes and additions. Branch is here: https://gitorious.org/gxml/gxml/commits/gsoc-acme
Importantly, some classes are changing their names to comply with the W3C DOM Level 1 Core spec, and the error handling methodology is changing to comply with GError's intended usage (that is, we're switching to g_error): the work there is mostly done in the branch gsoc2013 and will be merged soon.
Yup, I have been reading about these changes on your blog! While I haven't fully digested the question of what should and shouldn't be considered programming errors in the DOM api, I agree that programming errors shouldn't be exceptions here. This I think is also a problem with the libxml2 API I think, where every function returns a -1 on everything from passing NULL pointers to out of memory conditions to parse errors and IO errors. Difficult to sort out what needs to be handled and not. In XmlReader, I have used exceptions for two things: IO errors and parsing errors. In XmlWriter, only IO errors. It's another thing in languages like Java and C#, where you're not forced to declare and check all exceptions.
There's the general desire to at some point replace the libxml2 implementation behind GXml with a native GObject one, but I'm not in any hurry to do it because that's just more to maintain, and new bugs to fix. Daniel, I previously discussed rewriting it in Vala, but at GUADEC there was a strong concensus in favour of replacing it with native C, due to issues with libraries written in Vala, particularly from the experience of the libfolks developers (the most notable GNOME library written in Vala); again, I'm in no hurry.
Very interesting to hear. I read something about that on the wiki page for libfolks, I understand it's because new versions of vala will cause API breaks and vala is not near a 1.0 version any time soon. So basically what we're doing as a library that can guarantee stability for Vala code only. That's good enough for me at the moment. Good to keep in mind for the future, but for the moment let's just have fun programming in Vala. :-) I'm curious to hear more about what was said about this at GUADEC - when you say consensus, was this discussed at some session or is it just your impression when talking to various people? Also, have the libfolks folks written anything about their experience somewhere?
libvala's library name is itself versioned (e.g. instead of checking that libvala >= 0.18, it's actually libvala-0.18 >= 0.18, which I'm sure is wrong). I intend on copying what libfolks does to handle that. Regarding
Not really sure why we need libvala? If I understand it correctly, this is used for software that work with vala code itself, like Valadoc and such. In my previous setup (acme) I just checked for the existence of Valac with the AM_PROG_VALAC macro, this was inspired by the SQLHeavy (a library with a nice GObjecty interface to SQLite written in Vala) autotools setup. I tried this in gxml and it worked fine (is included in my patch), is there anything I'm missing..?
NodeType, hehe, the stringification of enums was awesome when I discovered it; I wrote that todo when I started this during GSOC 2011 and was relatively new to Vala. :)
Ok! :-) Hope you've had a good weekend, Simon Kågedal Reimer
Attachment:
0001-Merge-Acme-pull-parser-API-XmlReader-XmlWriter-into-.patch
Description: Binary data