DLIP: Desktop List of Installed/Installable Programs
Overview
The DLIP (Desktop List of Installed/Installable Programs)
is basically three parts:
- .dlip file format
- main.dlip central database
- dlip-lib libraries and/or commands to access the .dlip
The .dlip file format consists of two parts, the dictionary
of commonly used names, and the list of programs. The dictionary of
commonly used names is mostly used to store the names of menus and to define
URL types. The list of programs is indexed and has a huge amount of
information for each program. The information for any field can be
omitted, so you have as little or as much data as needed or available. The
format is binary (not human-readable), because human readable would take
up too much space and processing and because binary should be very small.
The main.dlip file is the crown jewel. It lists
all known programs with as much data as is available. The first listing
in the database (listing 0) will refer to the DLIP package itself. Each
program listing will contain the name of the program, description, URLs
for download, MD5 checksums, dependencies, conflicts, menu listings, and
more.
The dlip-lib libraries will primarily read the .dlip
files, look up listings, search for listings, write, and create new .dlip
files. Secondarily, it might scan for version numbers, installed programs,
updates, and other changes. It may download and install binaries or
diff-patches or it may download, compile, and install sources.
When the libraries are used alone, one can build his
own proprietary list of programs. Listing 0 can even be changed to reflect
a different DLIP package server. An operating system packager may wish
to list only approved programs. Red Hat, for example, is very security
and reliability conscious. They may choose to filter program updates
through a proprietary .dlip file. This differs from the current up2date
system, because it can be used to verify programs that are not included with
the distribution. Normally, the libraries are either used with the
main .dlip file (main.dlip) or with a slice of the file. (File slices
may be given their own index numbers, but that's currently not part of the
plan.)
The main.dlip file (remember, crown jewel) will list
tons of information about all known programs of all types. Why? To
add menu listings for currently installed programs, to provide a list of
programs available for download, to compare installed versions with current
available versions, and to verify that installed files have not been corrupted.
For the most part, the list is intended to be static. The problem
with regularly editing the file is that bytes would have to be shifted forward
and back. Of course, the list can be modularized to any extent, so
theoretically, the file system could handle all the adding and removing of
data by linking files, but that could cause a lot of fragmentation.
(I'm considering making two versions of the list: The
standard version of variable size and the huge file of fixed size. The
huge file would have a good speed advantage, since all entries and indices
are in a standard location. However, if the list has, say 100,000
programs, and if each program has 2K allocated to it, we're looking at 200MB
of mostly empty entries. The standard version file could be improved
by adding a buffer to each entry, but that still ends up bloating the file.)
History
5-23-03
After installing FreeCraft, dgen, Dark Places, a few
other games, a few window managers, and Netscape 7.02, I would normally not
make any menu entries or quicklaunch icons, because it's quite frustrating.
Netscape, for example, gets upset if I try to start Netscape with a
profile that's already open. There is a way to launch new browser windows
in a running profile, but I don't know it. Dark Places doesn't seem
to run from a launcher right, though it runs fine from a terminal window.
If I have Dark Places, that means I have XFree. If I have X, that
means I probably have a desktop or window manager. If I have a window
manager, I would probably prefer to launch stuff from the menu or an icon
instead of from the terminal. Why doesn't Dark Places automatically
make a menu entry? Probably because there are so many different desktops
and window managers. Should there be only one standard window manager?
No, that's not the Linux way. ;-) Instead, the window
managers ought to have a very easy, standard way that they can, if they
choose, locate programs and create menu entries. Back in the Windows
3.11 era, Windows would search the drive for programs to create entries
for in the Applications menu. This was generally the same idea, but
Windows would often misidentify files, because it only used the name of
the executable. If you have dm.exe, and it's something like "Dungeon
Masters" or "Dexxa Mouse", Windows is likely to list it as Disk Manager.
The DLIP idea is just the logical solution.
While deciding what information ought to go in the list,
the whole idea became more important very quickly. For someone new
to Linux, downloading, compiling, and installing a program and making menu
entries for it weighs in against the free price tag on most software. If
successful, the DLIP project would put software installation for Linux way
above any Microsoft or Apple OS in simplicity. (I have faith in Apple
that they will adopt and embrace DLIP and probably the open-source public-domain
community in general. Microsoft, however, has really dug themselves
a trench as they battle against Linux, and that trench could become the grave
of the software division.)
Capabilities
DLIP's main advantage will be it's openness, as in not
proprietary. It's OS independent and modularizable, and none of the
datem fields need to be filled. It's intended to be used with the
central DLIP server, but it can be entirely separate from the central server
by simply changing the first entry! If the DLIP format changed radically,
downloading the newest version of the package would download the libraries
which access it as well, which means that no incompatibilities will arise.
Features
DLIP has not yet reached it's first release. Keep
in mind that anything can change, but most likely more features will be
added.
-Standard way to search for installed programs
-Keep your software up to date
-Install programs from source or binary
-Verify the identity (and theoretically condition) of
executables with an MD5 checksum
-Retrieve up-to-date documentation and other URLs, such
as for online gaming
-Never worry about package conflicts!
-Never worry about dependencies!!
-If the data is kept up to date, then if DLIP can't
install it, it's probably very difficult or impossible to install.
Software
The DLIP package is intended to include just the libraries
and/or executibles to read .dlip files and optionally the main.dlip database
itself. Preferrably, anything beyond that will be fielded by the window
manager and desktop programmers.
Credits
Benjamin Vander Jagt, that's me, came up with DLIP and
submitted it as a public domain project on SourceForge. You can reach
me by telephone at 1(540)667-8388, by mail at P.O. Box 1398, Winchester,
VA 22604, or by email at benjaminvanderjagt at adelphia dot net. (Perhaps
my next project will be an alternative email link, perhaps in the form of
a GIF file, which spam bots don't read but which can be gleaned for information.)
Many thanks to SourceForge who have the greatest, most
well thought out service I have seen, at least in a long time. The
SourceForge team seems to be very wise and philanthropic. If they're
making profit with SourceForge.net, I'd be even more impressed with their
wisdom. ;-)
Legal Stuff
What legal stuff? I'm releasing this as public
domain. All software should be public domain.