Blam Atom reloaded
I have finally figured out how to tell System.Xml.Serialization.XmlSerializer how to load from an arbitrary namespace. It's not hard, it just lacks documentation on the Mono side of things. Searching USENET I found posts on .NET groups which directed me to the MSDN .NET page, and there it was, I just have to give my desired namespace as the second argument to the constructor.
What this means is that stable Atom support is definitely coming. The third-party Atom.NET library is not exactly stable, and I haven't seen signs of development for quite a while. The code is not pretty and an XmlSerializer approach is much cleaner anyway.
I am not sure whether it is worth it to release my code as a separate library. I'll keep it in Blam at least until I feel the API is stable enough.
In other news, school has started again, which takes time away from hacking. My router runs Debian now so it will me much easier to administer (it used to be a three year old LFS) and is going to be moved upstairs so we can all get easier sleep, which should make me less tired.
In the process, all network admin stuff (WLAN APs, Skype/DECT) will move out of my desk and I'll get gigabit Ethernet in my personal wired network.
Labels: blam
Everything happens at the same time
This weekend there was a wedding at which I was an usher, and the next day there was a birthday. We celebrated the wedding twice (sort of) and brought the birthday into it. There was also a change in citizenship involved.
After that, I suddently don't have much to do, but there have been a couple of moves around me.
Amaya NMU-ed Blam for an RC. Not having a laptop and moving around the continent don't leave me much time for hacking on it, but I'll get to in eventually.
Today I got a recruiting e-mail from Google. Apparently I have some skills they want. I'm going to accept of course, not least because there aren't any positions available close to where I live. Judging from what davej says, it probably won't be the last.
Obsoleting huge amounts of code
At the moment, Blam uses a library known as Atom.NET to parse Atom feeds. This is probably not a very big library by many standards, but it's actually bigger than Blam at about 7k LOC and to top it off it doesn't talk well with Atom 1.0
I thought there had to be a better way of dealing with those feeds, so I build myself a parser making use of Mono/.NET's System.Xml.XmlSerialization. With this I have a parser in 80 LOC, which will go down slightly when I remove one function which has become useless.
There are two erm... problems with this implementation:
- System.Xml.XmlSerialization doesn't understand the Atom namespace, so what I do is change the namespace when I read the feed and give that to XmlSerializer.Deserialize(). Yes, this is cheating, but it's for a good cause.
- Right now what you get is the raw information from the feed. It needs some helper functions, which should be a few hundred LOC.
This will make it into the Blam repository in a few days or weeks, depending on how much I get done.
Labels: blam
Going straight for Blam 2.0
I was going to release Blam 1.8.5 with a couple of minor fixes, but since it would be quite a minor release, I'm going to go straight for Blam 2.0
This means I'm going to start breaking the code in several interesting ways:
- The current GUI code has to go. It's an ugly hack and many things are provided by nicer GNOME/GTK standard code.
- The libraries are going to be worked on, even though I'm going to look for new RSS/Atom libraries. I'm going to try to use XUL instead of C to configure several aspects of how Gecko should work.
- The XML post-storage back-end is going to be ripped off and a file-based back-end is going to be implemented. This makes it easier to find out which posts have already been read. The Google Reader backend should be making it appearance when I finish implementing the other one.
As always, patches and comments are welcome. Check out the subversion tree and code!
And to think that when I first read a book about C# I decided to go back to good old C... Incredible what happens with FOSS.
Labels: blam
All Hail The Onion
I'm using the university's wireless network, but it seems like they have some sort of proxy: Any connection that doesn't go to ports 80 (http) or 443 (https) are closed with a 'no route to host' ICMP packet. This is bad, because anything interesting I can do with this network is right out (update git repositories, download mail, news feeds...)
"Ah!" I think, and download Tor (The Onion Router), set it up not to make the network angry and I'm in business. With the help of proxychains I can also use those programs which aren't designed to be used with proxies.
It's slower than what you get with the direct connection, but the alternative is not being able to use your favourite programs. I'll say it again, All Hail The Onion!
I have a GNOME account
Today I got an e-mail telling me my CVS GNOME account has been accepted. This means I have write access to the Blam repository. Unfortunately, I forgot to transfer the RSA key to my laptop, so I'll have to wait until I get home to upload it.
I may have already talked about this, but I'll explain my thoughts on using GNOME's CVS for development.
I really don't like CVS. I have at one point said that I hate it with a passion, but it's just a VCS, so it doesn't come to that. It's still really annoying to work with, though. Everything has to go to the server and it doesn't fit my development model at all.
SVN is partially better. Creating diff files is much faster (which I use a lot) and I can reset files with ease. I haven't used it much. I don't know if it allows local branches, but I don't think so.
The main problem with centralised VCS is that a lot of stuff has to go through the server. I create throw-away branches quite often, and work on several things at once. Distributed VCS make this easy, which is why I like them (I almost instantly began using GIT for all my projects). The way to make this work with centralised ones is to use some tool like quilt (I use STG with GIT, distributed systems and branches aren't the be-all end-all of my hacking problems) to solve some of the problems.
My plan was to use GIT for development and use CVS for patches which I knew for sure were going in the released version. I'm still committed to using the VCS at GNOME, as it's the canonical source for upstream. I already have to script the release much more, so I'll just add publishing to GNOME in there.
And don't worry, I'm still going to release the proper 1.8.4 version soon, but I have to find the patch I was going to apply.
Fun Blogger fact of the day: When you try to publish incorrect HTML, it shows an error.
Blam keeps moving forward.
I've had busy week with Blam. You can look up the new features in the page, but to sum up, it's much more usable.
The source packages are a bit hosed, so you should run ./autogen.sh in order to get it to work. There are also Debian packages available, which I think should work with most derivatives (I'll see about getting an Ubuntu version built, but for now these should work). It's only for amd64 and i386, as that's what I have access to, but that'll be most of you anyway.
Labels: blam
