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
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
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
HTTP authentication and HTTPS in Blam
I have finally implemented HTTP authentication (totally insecure unless used with HTTPS) and SSL certificate error ignoring in Blam. This means you can get a file in a folder protected by an .htaccess file and that you can access feeds in sites with a self-signed SSL certificate.
The latter only happens if you activate "Ignore SSL certificate errors" in the preferences. If you don't it will crash (definitely something to be fixed before long).
Whilst I was writing this entry, and being inspired to by Jorge, I have finally implemented using the clipboard's content as the default URI for a new feed. And now a feed's name will contain the URI until we receive the feed and can parse its title. This should bring the bug count down a bit.
Labels: blam
New blam release
I released blam 1.8.3 last night. The only thing that has changed since pre1 is the addition of a manual page and the version number. The 1.8 releases will stilll have Mikael as author, as he has done basically all the work.
The Debian package has hit unstable so it should reach your local mirror soon, which means this version should still make it into Etch (Debian 4.0).
Development will slow down, as the exams are coming, and I will be busy during the next couple of months. I will hack on it more next year, but I don't know how much time I will have.
