... suck.

The XML Schema "datetime" format can't be handled by Java's SimpleFormat (ok, that probably is more Javas fault, of not being able to handle hours:minutes in the timezone specification, anyway, this is mildy annoying).

The XSLT2 parsers are very intolerant about the format of the time specification, too. They could have made more stuff optional such as the specification of seconds; an error here will make the whole XSLT fail with an exception. Some compact form of error handling would be nice... as would be a smart parser which can handle various formats.

The XML Schema "duration" is even worse. First of all, it was completely forgotton when doing XSLT 2; there are no functions to format or disassemble it (except by regular expressions, which could also use a zero-width lookahead).

Secondly, it's lacking common specifications such as "next week". While "next week" is computationally equivalent to "in 7 days", it can have different semantics in some contexts (especially when not being aligned):

If I'm looking for the week February 9th 2007 is in, the result is February 5th two February 11th. If I'm looking at a 7 day interval containing this day, there are infinite possibilities (aligned on milliseconds and below...). So it does make sense to make a difference between 7 days and a week.

So far, DBus has two types of busses: the session and the system bus.

The session bus is used by most of your desktop applications.

The system bus is used e.g. by Hal signalling that new hardware was added, or by NetworkManager for network connectivity changes. The system bus is protected via a security policy.

Problems arise now when you need to locate your session DBus from a different session. For example, from a cron job.

There is a DBus application called "notification daemon" which can display popup baloons. This is useful for signaling yourself e.g. the completion of a long-running computation or just about anything you want. But it's using the session bus, so you can't reach it from outside of your current session.

A year ago, I wrote a hack for this, which will locate your current Gnome session, read the environment variable to find the session bus and then send a message to the sessions notification-daemon.

This is an ugly hack, however yesterday and today people asked on #dbus precisely how to do this. It seems to be a common question.

Maybe DBus should be extended by a "user" DBus, and applications such as music players or the notification daemon should actually listen on that bus (as well).

Maybe it could also be made possible to (securely) locate your session DBus via the system bus, I don't know how detailed the security policies of the system DBus are.