Messages in this thread | | | From | Michal Jaegermann <> | Subject | Re: albods are not a clean set of orthogonal primitives (was Re: File | Date | Fri, 25 Jun 1999 20:56:55 -0600 (MDT) |
| |
Wanderer wrote: > > Pretty good summary , but ... Issues like user specific overrides of > components are really an application issue.
That's what I said. No? But making such things harder or easier is a question of an overall design.
> As an example, KDE has > icons, themes, wallpaper, etc. for the installation (base bundle),
Still elements of this bundle are simply files. In a case of a wallpaper just a bunch of jpegs. It means that I can replace them, throw away or add some to "system defaults". As a user I can have still some extra wallpapers on my own. If they would be packed together in, say, 'ar' archive then doing that would be much more difficult - especially for "non-root".
> Of course, if the bundle is a user's private application, he can just > 'cp new bundle/old' and the element is replaced. This is why I want > a tag or signature that indicates that the bundle is not in a pristine > form.
I still claim that it is very important to be able to leave a pristine bundle and still override some its elements on a case by case basis. Even if this capability would be used not often that is important to have it. The whole flexibility and configurability of NeXT interface, for applications which are already compiled and for which you never seen a source, relies on the fact that .nib is a just a file in .app bundle.
> > Putting things together in an 'archive' (as you put it) is mandatory > IMO. The entire issue is that many items simply have no > significance on their own.
They __always__ have significance on their own - even if simply as replacements of defaults.
> This can vary from simple international > strings and icons, to entire application suites.
Yes, exactly. You just hit the nail. This means, for example, that if your language is obscure enough that nobody bothered with internationalization then you are able to that yourself with a proper tool. It also means that internationalized application does not have to carry around a baggage of 120 sets of different languages strings when you absolutely do not care about 117 of them and you can pick some interesting for you, if they are ready, from some net archive. Already some i8n stuff in distributions, with only ten languages or so, starts to look weird and obscene and this just a beginning. OTOH some of your users may want to have something in Bahasa Indonesia or Swahilli and you offer only few European ones plus an odd Chineese. Even if a disk space is getting cheaper beeing swamped in a zillion of pieces, even if bundled within some archive, most of which have no relevance or use for you but may be vitally important to somebody else, is not a very good management policy. And does not matter what - you will pay a performance price for that. Today this is negligible but pretty soon you will have to answer why not Navajo or Cree; and why not?
> Does it make sense to > have a utility that manages FooBar Document Folders when you > don't have the FooBar Application to create the document?
You never played with an InterfaceBuilder on NeXT, right? The answer is "yes, it definitely does". Not always but there are enough cases already existing and I will not try to predict what future will bring. Closing a design because of a current lack of imagination is not a very good policy.
> The kernel shouldn't > care about the content and use of these 'bundles' beyond allowing > proper access to them.
We violently agree on the point. :-) My point is only that 'bundles' should not be overdesigned and require special tools to access components. And after all this is not a concern of a kernel as long as it does not **require** something like that.
The same NeXT I quoted above made a horrible mistake of bundling all configuration data in one big binary blob called Netinfo. Some people argue that this is great - all information in one central place where it can be managed easily. They obviously never had a pleasure to rescue a machine which does not boot because data got corrupted somehow, for whatever reasons, or a network configuration simply changed and there is no way back to the previous state (a machine was shipped to another city, for example). This is not funny at all. Tools which could help you, maybe - this is very far from sure, are not available because the bloody box does not boot. All of this because somebody decided in their deep wisdom and foresight that these particular pieces of data "have no relevance on their own". I lost enough of sleep due to this great design and it still beats 'doze Registry by a mile. :-)
Yes, after a while you can become good enough in esoteric hacks to recover from such disaster although "recovery" may mean that you lost all or most of your configuration data and you have to start from scratch. Still I know cases when people where not knowledgable or patient enough and took "Microsoft escape hatch" by reinstalling the whole system from ground up in order to get a computer back.
Michal michal@harddata.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |