Harold Kelley would be proud
This is really where the beauty of my utopian system starts to shine. Attributes in the BFS filesystem, combined with the concept of live queries, enabled you to do all sorts of crazy stuff with the files on your BeOS machine. Back in 2005, when I reviewed Zeta R1, I already explained a few interesting uses of BFS live queries:
Another interesting scenario to use BeFS is when you are putting songs on your MP3 player. Want all music from Bruce Springsteen? Or all songs from the Devils & Dust album? All songs from the 'rock' genre? You can do that without ever touching a music player or other specialized applications.
You are only limited by your imagination.
And you really are only limited by your imagination. Combine the concept of live queries and attributes with program bundles, separate setting files on a per-user basis, and the possibilities are endless. Seriously.
Each program bundle can store the basic information in attributes, the stuff you'd expect: name, publisher, date of release, country of origin, names of the main contributors, website, license, and so on and so forth. The boring stuff, but handy when you forget where you got the application from. There is also the attribute that takes care of the 'linking' with the settings files, but how exactly this would work, I don't know - I'm leaving this up to the programmers and coders.
I also want to introduce a concept alongside the version number. When we think of version numbers, we tend to think of the numbers dangling at the end of releases, which are usually fairly arbitrary and don't really say anything at all. Those would become 'external' version numbers. What is new is the 'internal' version number. How programmers order these numbers is completely up to them, as long as the second release's internal version number is higher than that of the first release. This is essential.
Take Garden Designer. You have Garden Designer 8.0 installed on your system, which happens to carry the internal version number of '348'. Now, say Garden Designer 8.1 is released - the idea with program bundles is that various releases are named the same. This new version should get an internal release number that is at least 348+1. This way, the system can compare the attribute for "internal version number" and see that the program bundle Garden Designer 8.0 carries an internal version number of 348, while Garden Designer 8.1 carries 349*.
From this, the system concludes that 349>348, and will update the program bundle accordingly. However, the fun doesn't stop here.
Who says you would want to replace version 348? What if you're unsure about version 349? You may have heard horror stories online, you may have had a bad update experience in the past, or you may be running a production system. Well, simply tell the system to allow the program bundles for version 348 and 349 to live side-by-side, so you can continue with 348, which you know works fine, and test 349 before ditching 348. Combined with the ability to sandbox program bundles (see the privilege section) this allows you to do extensive non-destructive testing on your system. It also enables you to easily switch back to an older version - a prompt would warn you the version you are about to install is older, but if the newer version doesn't work as expected, you can ignore the dialog and replace the newer, broken version with the older, working one. Fairly hassle-free.
A few of you are probably worrying about the settings files in
/Settings right about now. How would the settings files deal with multiple program bundles of the same program? The answer is straightforward: think attributes again - the settings files can carry the same attribute for "internal version number" as the program bundles themselves, so you can easily have multiple settings files living side-by-side peacefully. Using live queries, you can search for unused settings files (using the attribute that links them to the program bundles), and clean them up accordingly in case you want to remove old settings files that you thought you might need in the future when you deleted their applications.
Now we can finally come to the centralised updating issue. Some of you will have probably already done the math, but here it goes anyway: I envision a centralised repository of program bundles, all tagged - of course - with the proper internal version number attribute. A very simple application could check all your programs' internal version numbers using a live query, and compare them to the internal version numbers of the program bundles in the repository. You could tell it to prompt you for each update with the replace/side-by-side option, or simply have it update everything.
The centralised updating tool being built on top of a set of live queries, it could be made as complicated or as simple as the programmer would want it to be. You can do simple queries like "search for outdated programs and update them", but also more advanced and detailed queries such as "search for outdated programs from Microsoft and update them", or "search for program bundles with multiple versions installed and list them", or whatever other possibility that might be useful. And the beauty of it all? Live query support is built right into the file manager in BeOS, so you can do all this manually if you don't like the available centralised update programs. Ultimate control for experts, hassle-free updating for inexperienced users, and anything in between.
If you like a centralised method of managing applications - use the centralised updater/installer tool. Don't like it, and prefer a more manual approach? Don't use the centralised tool. The choice is yours.
* Why not use dates instead of these numbers? Two reasons: date formats differ across the globe, and you have different timezones that might interfere with such a system - you'd need a method of working around such a problem, which would just introduce another complication to the system.