Application Encapsulation Ideas
From jeske@.. Wed Jun 10 02:16:00 1998
Message-ID: <19980610021600.B3088@home.chat.net>
Date: Wed, 10 Jun 1998 02:16:00 -0700
From: David Jeske
To: *** KDE ***
Subject: encapsulation of installed items
Mail-Followup-To: *** KDE ***
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.92.1
Status: RO
Content-Length: 3142
Lines: 75
Hello,
I have looked around and not found any discussions of using some kind of
real encap system for KDE applications. I'm surprised. KDE is the graphical
half of making Linux a more 'newbie friendly' OS, but improving the UNIX
filesystem crazyness is the other half.
This problem (IMO) has been _solved_ before. Take a look at
Nextstep/OpenStep/Rhapsody.
They used directories with extensions to encapsulate items (applications,
loadable plugins, development frameworks, etc). I'm just going to talk about
the application issue to begin with..
Just arrange all application files within a '.app' or '.kapp' directory.
Locate the application binar(ies) somewhere known for the platform. Require
'kde conformant' apps to call a kde supplied 'kde_get_app_root_path()' or
better yet, 'kde_open' and 'kde_fopen' instead of standard open/fopen.
For example:
KAudio.app/
KAudio.app/linux-sparc/KAudio
KAudio.app/linux-i486/KAudio
KAudio.app/.dir.ico # app icon!
KAudio.app/my_app_file
KAudio.app/another_my_app_file
Where you could automagically display '.dir.ico' in the filemanager
without any configuration files or scripts, and automatically launch the
appropriate binary when someone double clicks on the 'hidden' .app
directory. (i.e. when you come to the .app directory in the filemanager, it
should default to launching it, not opening it as a directory)
This way, applications are discrete packages which are contained completely
within their directories. They are no longer troubled with the silly UNIX
dependence many apps have on 'being installed where they were compiled to be
installed'.
Furthermore, you can easily extend this in simple ways to automatically have
the file manager configure what filetypes the app can open, and stuff like
that (just like nextstep did). NS would just have a set of 'app paths' in
which it would look for apps. (just like $PATH, except it was looking for
the encapsulated app directories to parse, not the binaries to run). Then
you could store datafiles in the appwrapper like:
KAudio.app/___kde_myfiletypes
KAudio.app/___audio_wav.ico
KAudio.app/___audio_mp3.ico
which would contain something like:
%%kde_filetype_def_v1.0
*.wav; audio/wav ; ___audio_wav.ico ; "Windows WAV audio"
*.mp3; audio/mp3 ; ___audio_mp4.ico ; "Mpeg1 Audio Layer 3"
*.au; audio/au ; ___audio_au.ico ; "Sun AU Audio"
Once the filemanager builds this list, it's trivial to have it autolaunch
applications for appropriate filetypes. Furthermore, it's also trivial to
have a panel to configure the user's preferred app for opening given
filetypes, or selecting from one of the applications which handles a given
filestype.
If you have never seen or used Nextstep, then you listen to people who have.
If you have used Nextstep, and think this encapsulation idea is bad, and
that it's much better just to throw bins in /usr/local/KDE/bin, I'd like to
hear the reason why.
They also do similar things in the Be camp, although they have proper MIME
type attributes on files to do it with (instead of extensions).
--
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@...
From jeske@... Wed Jun 10 11:32:35 1998
Message-ID: <19980610113234.H4294@home.chat.net>
Date: Wed, 10 Jun 1998 11:32:35 -0700
From: David Jeske
To: *** KDE ***
Subject: encapsulation of installed items (re-summarization)
Mail-Followup-To: *** KDE ***
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.92.1
Status: RO
Content-Length: 2669
Lines: 52
Let me begin again for those who have started to discuss specific feature
characteristics of what I'm talking about. I want to provide the following
things for installed KDE apps. I would like anyone to please comment if
they think any of these are a bad thing:
1) apps should be encapsulated from all other apps
2) you should be able to install multiple versions of the same app
at the same time
3) Applications shouldn't have control over where they store their
data (i.e. compile time install location dependencies)
4) The administrator (possibly the primary user) of a machine should
be able to organize apps the way they see fit, and non-administrator
users should be able to install apps privately for themself
5) apps should be easy to install
6) apps should not 'graft' themselves into the system, making changes
to many system files in order to make themselves known to the system,
because there is no way to track back ALL these changes to the app
when it needs to be deinstalled...
7) Applicationship should be able to publish information like: the
types of files they open, and the icons for those files.
8) I should be able to easily delete an app at any time, regardless
of where or how it was installed.
Now, if you are still with me, I argue that the following points are
necessary features for the above to be true:
1) apps must be installed in their own private directories, this is
necessary to install multiple versions of the same app. To be
very clear, there should be a directory which contains all of the
executable and data-files required for a given app and NOTHING ELSE.
(henceforth called the 'app-wrapper')
2) apps must be required to access their local datafiles by using a
specific relative API. Namely, they should replace this:
fd = open("$KDEDIR/bin./my_datafile");
With this:
fd = kopen_rsc("my_datafile");
3) apps _must_ be passive. That is, they should have enough information
in them to export all the things they can do, but they should NOT
put that information anywhere with some 'install-shield' or 'redhat
package manager'. If you want to cache this data, then you can
go through all the passive packages and pull this information out,
however. I should be able to at any time rebuild the current
'app environment' from nothing more than the installed app-wrappers
themselves.
It is my understanding that the current KDE app installation/runtime
requirements do not meet these points, and thus are incapable of providing
the features I believe are necessary.
--
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@...