[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-look
Subject:    Re: Moving away from app-centric mimetypes (e.g. kword)
From:       "Friedrich W. H. Kossebau" <Friedrich.W.H () Kossebau ! de>
Date:       2002-05-19 14:23:52
[Download RAW message or body]

Steven D'Aprano schrieb:
> 
> On Sat, 18 May 2002 22:17, David Golden wrote:
> > On Saturday 18 May 2002 04:25, Steven D'Aprano wrote:

[SNIP]

> > Files are a place where people store
> > related information. Directories are a place where people store
> > related files. Files are Information.   Why can't I CD into the
> > permissions of a file, or CD into its mime type ?
> 
> Why would you want to?

To have direct access. You step down to a layer where the things you
want to work at are lined up (exclusivly) in front of you. But read
above.
 
> > Directories ~ Files.
> 
> I don't understand the ~ symbol. Is this supposed to be
> "approximately equal"?
> 
> > for metadata, one can invisage a directory interface to "classic"
> > unix permissions, for example.
> > (I'm not saying this _particular_ scheme is any good, just an
> > illustrative possibility..)
> 
> Okay, I see how it works. But why?
> 
> What else can you do? cd into a mp3 file or jpeg or text file? I don't
> understand the point.

ls a text file: line 1, line 2, line 3, line 4, ...
cp a mp3s comment: cp new_comment newyorknewyork.mp3/comment
edit a jpeg file: khexedit image.jpg/block3x4

Compare this with kio-slaves. They give you consistent access to data
using the concept of "files". A file is a collection of data which
structur isn't further analysed. It is simply passed by as a package of
bytes that is dealt by an app that is capable of understanding the files
structure/format. 

A file is where the concept of storage of data has a break. It is a
pragmatic break as usualy the data stored in a file is strongly bound to
each other and that make only sense together. 

But there are things that doesn't fit in this:
1. The direct access to a specific data in a file, like the entry for
the mounting of /boot in fstab, or the comment in a jpeg file is not
possible. You need extra apps that are aware of the specific structure.
2. Shared data entities. Want to reuse a image used in a kword-document
(in its former format)? You have to copy the data although you use
exactly the same image. If there is direct access to the data structure
one could simply make a link to the image in the kword file (not a
perfect example as, like in other word processors, the image could be
moved outside the word file back into the filesystem and be simply
referred to, so it will be accessible by other apps/files, but I hope
you get the point) 

> 
> [snip]
> > Most complex file formats effectively incorporate half-assed
> > directories or full database  structures already.  XML _is_ a tree
> > structure.   (XML is just lisp sexps reimplemented badly, too, but
> > that's another rant) The windoze registry.... argh. argh.. argh..
> >
> > One can easily imagine:
> > cd <ELF-FILE>
> > ls
> > ...segment 1
> > ....segment 2
> 
> An observation here. Long ago, when I was young and foolish, I tried
> programming some mid-level file manager stuff on the Apple Mac. Now the
> thing with the Mac file manager is that is has (or had) three tiers:
> high level routines for opening files, low level nightmares for doing
> weird things that nobody sensible would want to do, and a mid-level.
> 
> The mid-level routines basically had a single command (say, hfopen)
> which took a complex data structure, and that data structure varied
> according to whether you wanted to open a file, or a directory, or a
> device driver, or a volume. It was a mess to use, and it must have been
> a nightmare to maintain.

A perhaps bad implementation needs not to mean the idea behind is bad ;)

> If I have understood you correctly, you are suggesting something
> similar. You are suggesting that cd should work on files, directories,
> presumably pipes and devices and anything else that can show up in a
> directory tree. Presumably you want to cd into a tar file, and a gzip
> file, and a xml file, and any other file.
> 
> So who is responsible for updating the cd command for every new file
> format that comes along? When I try to cd into a Metacard file (.mc),
> and I don't get the result I expect, is that a bug in the cd command?

No bug but a not yet implemented feature :) Or the fault of the new file
format's inventors: Why did they use a new format, why didn't they leave
more structure on the filesystem's level?

One has to deal with the fact that there are all those formats today,
with the data structure not being integrated in the filesystem. In
KDE/Konqueror-Terms they all would need a kio-slave that gives
structured access to the file's data. At least this would offer direct
access.

Lets take the mp3-example: There might be a mp3contentbrowser-slave that
is default for left mouse button click. 
In directory
	file:/home/kossebau/music/frankyboy
you click on newyorknewyork.mp3 and will access
	mp3content:/home/kossebau/music/frankyboy/newyorknewyork.mp3
where the file view shows you 
	a file "comment" of mimetyp text/plain and 
	a file "sound" of mimetyp audio/mp3-raw (or the like). 
 
> > > > kword and staroffice already do this -
> > >
> > > They do? Explain please.
> >
> > Staroffice's file formats are zipped directorys of xml files,
> > according to another post on this ML, so too are kword.   Java jars
> > are zipped directory trees. See a pattern?
> 
> Yes, but I fail to see the relevance.
> 
> I think you are making an error of terminology, and that is giving you
> the wrong idea.
> 
> A Staroffice file isn't a zipped *directory* of xml files, its a zipped
> *set* of xml files. The reason being, you can store anything you like
> in a directory. If I add and remove xml files at random from
> /home/steve/myfiles/, I'm not going to break anything. But if I add and
> remove xml files at random from a staroffice file, I will surely break
> it.

Good point. But this could be handled by ACLs. Unless declared
differently only staroffice file handling apps are allowed to write,
move and delete files inside a staroffice file directory/structure.  And
further...

> (Whether it breaks gracefully or explodes in a shower of flames is
> besides the point -- its still broken.)

... when it can be broken this way there may be something wrong in the
design. If one removes a file (data entity) it simply isn't there
anymore. Remove a image file from a kword "file" - isn't this like
removing it using KWord? Even if you remove the central layout - it
simply isn't there anymore but the text files and image files still are.
If Kword misses a file that is referred to it may simply ask the user if
he wants to correct the path or if the reference should be deleted.

Besides you don't that often add and remove files at random, do you ;) ?
 
[SNIP]
Friedrich

[prev in list] [next in list] [prev in thread] [next in thread]