Monthly Archives: July 2005

HTTP resource watcher

  • Post author:
  • Post category:Uncategorized

I’ve got most of the features of my HTTP resource watching code I was working on for GWeather done. The main benefits over the existing gnome-vfs based code are:

  • Simpler API. Just connect to the updated signal on the resource object, and you get notified when the resource changes.
  • Supports gzip and deflate content encodings, to reduce bandwidth usage.
  • Keeps track of Last-Modified date and Etag value for the resource so that it can do conditional GETs of the resource for simple client side caching.
  • Supports the Expires header. If the update interval is set at 30 minutes but the web server says that the it won’t be updated for an hour, then use the longer timeout til the next check.
  • If a permanent redirect is received, then the new URI is used for future checks.
  • If a 410 Gone response is received, then future checks are not queued (they can be restarted with a refresh() call).

I’ve also got some code to watch the HTTP proxy settings in GConf, but that seems to trigger a hang in libsoup (bug 309867).

While I wrote the code for use in GWeather, it could be quite useful for other tasks that require watching an HTTP resource such as:

  • HTTP calendar backend of evolution-data-server.
  • A stock ticker applet like gtik.
  • Possibly an RSS reader.

The code is available in my Bazaar archive:

baz get http://www.gnome.org/~jamesh/arch/james@jamesh.id.au/http-resource--devel--0

Going to Brazil

On Sunday I will be going to be travelling to São Carlos, Brazil for two weeks of the Launchpad sprint. It will be my first time travelling to either Brazil or South America so should be fun. That leaves just North America as the only major continent I haven’t visited.

Bryan’s Bazaar Tutorial

Bryan: there are a number of steps you can skip in your little tutorial:

  1. You don’t need to set my-default-archive. If you often work with multiple archives, you can treat working copies for all archives pretty much the same. If you are currently inside a working copy, any branch names you use will be relative to your current one, so you can still use short branch names in almost all cases (this is similar to the reason I don’t set $CVSROOT when working with CVS).
  2. If you have a directory which contains only the files you want to import into your Bazaar archive, the following command will add them all, and convert the directory into a Bazaar working copy:
    cd background-channels
baz import -a bclark@redhat.com--gnomearchive/background-channels--dev--0.1

    No need for init-tree, add or commit.

  3. Running archive-mirror in your working copy will mirror that archive, so doesn’t need my-default-archive set.
  4. Other people probably don’t want to set your archive as their default. Also, they can ommit the register-archive call entirely:
    baz get http://gnome.org/~clarkbw/arch/background-channels--dev--0.1

    This checks out the branch, and registers the archive as a side effect.

  5. If you want to find out what is inside an archive, the following command is quite convenient:
    baz abrowse http://gnome.org/~clarkbw/arch

Some things you might want to do:

  1. If you have a PGP key, create a signed archive. This will cryptographically sign all revisions. When people checkout your branches, the signatures get checked automatically (this is useful if the server hosting your mirror gets broken into and you need to verify that nothing has been tampered with). If you have already created the archive, you can turn on signing with baz change-archive (remember to update the mirror archive too).
  2. If you turn on signing, consider using a PGP agent like gnome-gpg. You can configure it in ~/.arch-params/archives/defaults.
  3. It is customary to name the archive directory the same as the archive name. This has the benefit that the branch name matches the last portion of the URL.
  4. If you haven’t set up a revision library, you should do so:
    mkdir ~/.arch-revlib
baz my-revision-library ~/.arch-revlib
baz library-config --greedy --sparse ~/.arch-revlib

pkg-config vs. Cross Compile and Multi-arch

One of the areas where pkg-config can cause some problems is when trying to cross compile some code, or when working with multi-arch systems (such as bi-arch AMD64 Linux distros). While it is possible to use pkg-config in such systems by manipulating $PKG_CONFIG_PATH and/or $PKG_CONFIG_LIBDIR, users can’t just follow the instructions given for the single-arch case.

After some discussion with Wolfgang Wieser, we came up with a proposal for better supporting cross-compile and multi-arch uses. The main changes would be:

  • Add a new --host option pkg-config. This would allow pkg-config to use different default search paths based on the host type, and search for .pc files in host type specific subdirs on the search path.
  • If an unknown host type is given, then no default search path is disabled altogether.
  • The autoconf macro would pass this argument whenever it detected that pkg-config supported it.

For the common case, this should allow most packages to be built for the non default architecture on a bi-arch system, or cross compiled, by just passing --host=foo to configure and (you might still need to set $CC or $CFLAGS, depending on the compiler setup).

For packages that install .pc files, they should continue to work. However it will be worth updating them to install their .pc file into a host type specific sub directory (the autoconf macros will make this easy to do).

If this code is likely to affect you, send comments to the pkg-config mailing list (or leave comments here).