OpenOffice.org is a great piece of software. And at what better price could you get it? But as with everything, there's always room for improvement.

LDAP has a very powerful path specification language. Unfortunately, it's somewhat more cumbersome than XPath, and familiar to fewer people than other more well-known tree navigation languages such as XPath and glob().

I'm proposing that the next version of LDAP have an option to use TreePath-based paths (as described in TreePath -- a universal tree navigation language) as well as the traditional LDAP ones.

glob(), as I said in the article "TreePath -- a universal tree navigation language", has its good points, but is lacking in power. It's time an upgrade was done.

What advantages would XPath gain from using TreePath? There are a few:

• Simple TreePath would provide a simpler alternative to XPath
• If the TreePath language becomes more widely used, people will be able to learn XPath more easily because it will already be familiar.
• If TreePath becomes more widely used (eg. in filesystem navigation), there will be a much larger pool of people contributing to and optimising it.

I'm not a die-hard XML fan. It has its place, but it's not the best thing ever. But there is one thing about the XML milieu that I really do like.

In the previous article in this series, we discussed how it might be possible to produce a unified package management system. Probably, though, I've personally had more trouble from package meta-managers (such as yum, apt, and up2date).

They have lots of features, but not always the ones I want. The answer is increased modularity, configurability, and standardisation.

One of the things which seems to have been reinvented by every version of Unix and every distribution of Linux is the package management system. This post makes suggestions as to the best way of achieving a unified package system.

The idea

When I say "Domains", I don't mean DNS domains, but merely unique strings that identify a domain-set of users. This might include DNS domains, but it would not be limited to them.

This would mean that software that wished to authenticate users (such as MySQL), but didn't wish to create local users would have a mechanism for doing so. Then we wouldn't end up with 101 different authentication systems like we have now.