[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:       "Steven D'Aprano" <dippy () mikka ! net ! au>
Date:       2002-05-26 1:52:22
[Download RAW message or body]

On Mon, 20 May 2002 00:23, Friedrich W. H. Kossebau wrote:
> Steven D'Aprano schrieb:

> > 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, ...

Why list by lines? I have a text file that is set out in paragraphs of 
multiple lines, so therefore ls should return paragraphs.

But wait, I have another text file which is set out in logical units of 
tab-delimited words, so therefore ls should return words.

I also have a comma-delimited text file... do you see the problem? Any 
assumption you make about the internal structure of a text file is just 
an assumption and *will* break for some subset of text files.

> cp a mp3s comment: cp new_comment newyorknewyork.mp3/comment

And how does the cp command know the valid names of metadata inside 
binary files? How does it tell what is valid data and what isn't? What 
a great way to break files:

cp big_binary_file 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.

Which leaves responsibility for understanding the internal structure 
where it belongs, at the app developer, instead of expecting the ls and 
cp and cd commands to magically understand every imaginable file format.

[snip]
> > 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. 

More complication for the cp and mv commands to understand. Not only do 
they have to understand the format of every imaginable binary file, but 
now they have limit read and/or write access to only certain apps. 
Which defeats the purpose of having cp, mv, ls etc operating on 
internal data within files.

> 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.

And how do they render?

What if you remove the image size properties from an image? Does the 
image default to a random size? Or just disappear, even though the 
image is in the file?

> 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.

Oh yes, Joe Average User will really understand that. "Correct the 
path? What does that mean?"

> Besides you don't that often add and remove files at random, do you
> ;) ?

You obviously haven't done much desktop support, have you?


-- 
Steven D'Aprano

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