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/