Re: Files with a substructre should be directories.

"Friedrich W. H. Kossebau" <[email protected]> Sun, 26 May 2002 15:38:39 +0200
Newsgroups gmane.comp.kde.look
Message-ID <[email protected]>
Sven Niedner schrieb:
> 
> On Monday 20 May 2002 10:34, Friedrich W. H. Kossebau wrote:
> > I wanted to use the mp3 files as an _example_ for a file with further
> > structure. Should have used a better one as comment is declared as
> > metadata so this was confusing, pardon.
> 
> Strange how much all this reminds me of NeXT Step; it was ahead of its
> time by more than 10 years and provided solutions to problems that we
> start to _discuss_ now.
> 
> However, the NeXT Step approach was 100% UNIX-like: A file with
> substructure was -- a directory. The directory extension .app stood for
> applications, and others existed as well. The application icon was
> stored in this directory under a special name (in TIFF format, BTW),
> and the resources for the GUI were contained in the directory as well
> as required libraries. Even from the UNIX shell promt, the substructure
> was accessible.

Great. Thanks for this information. So there is a reference to use when
argumenting for this approach :)

This reminds me of a thread on kde-devel about handling of directories
with mp3-files in konqueror. There was the need for the start of a
mp3-kpart on click at such a directory that loads all mp3-files in the
directory. Someone (uhm, was me) proposed to invent mimetypes for
directories so there could be an association of the mimetype
application/album with the kpart showing and playing the mp3-list. 

The mimetype would be based on the ending, e.g. ".album", so the
directory "BestOf.album" would be of mimetype application/album. You
still are able to access each mp3-file on filesystem level.

> For the transport, etc. of these "files", one can easily use tar,
> compress them with gzip, etc.

Would need support by the apps doing the transport but this should not
be a great obstacle, the algorithms are inplace (system( "tar ..." )
would be a beginning). Until then it has to be done manually.

> I really advocate for a similar solution. The strength of UNIX lies in
> the command line and in batch processing. Not for the desktop user, but
> for the servers. But rather soon, there won't be any desktops without
> servers. What p***es me off most in Windows is that there is no
> reasonable and easy way to do scripting from a command line. If we give
> up shell access to the KDE file, we loose the most important features
> of UNIX.

Amen.

Friedrich