[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-26 13:39:32
[Download RAW message or body]

Come on, Mr. Contra, try at least do understand what I _want_ to say ;)

Steven D'Aprano schrieb:
> 
> 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.

The question is: What else _could_ you do? This is all theoretically, as
today's filesystem/data storing and relating filesystem access apps
don't support it.

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

Yes. The _real_ mimetyp text/plain doesn't seem to have a standard
formatting, that is where this _theoretic_ handling breaks. It's time to
improve the mimetyps, then.
 
> > 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:

This is not about mp3 files in binary format, but in a filesystem
supported format... wrong file names would be then comparable to a
private letter file in your working stuff directory. Once again: ACLs
(in terms of allowed files/mimetyps) would be your friend.
 
> 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, 

Of course!??? This is the Windows(tm) approach. Are _you_ happy with it?

Don't restrict some because of the fools. Give the fools the apps they
can use, but have the others do what they want to and could do. To use
the filesystem for structured data more than it is today would make the
life of many easier. 

The internal structure of a file is so often similar to the conceptual
structure of the described object, a corresponding spreading on the file
system and the access won't be that difficult to handle.

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

Once again: I am opposing against today's encapsulation of data in
files. This is all about what could it be and how intermediate working
could be done.

Did you read Sven Niedner's email of today? He describes the approach of
NeXT Step. They put more structure on the file system. It is possible
then. And no, NeXT Step didn't fail because of this IIRC ;)

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

One should have a reason for mving of files... If one often does wrong,
use file managers with support for undo.

> > 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?"

Then Joe should not be allowed/enabled to handle files outside of apps
unless he learned about the concepts of directories and paths.
Joe II might read the better message:
"The image "My new car" with filename "mini.jpg", used on pages 2 and 8,
is supposed to be stored in directory "joe:My Images" but could not be
found there. Do you know where it is stored now, should be searched for
it or do you want to treat it as temporally not accessible? Or don't you
want to use this image in this document anymore?"
and understand, won't he?

> > Besides you don't that often add and remove files at random, do you
> > ;) ?
> 
> You obviously haven't done much desktop support, have you?

Well, only to my mother and some friends, mostly smart luckily. But my
strong believe is that there is the need for _really_ simple apps for
those not willing (or being able) to learn computer sciences. Does
everyone need filemanagers like explorer or konqueror having access to
(and view of) all files and, even worse, directories? What does a person
do? Write word documents, doing emailing? No need for a file manager.
The storing and grouping of the files could be done automatically, the
file dialog would be a simple one, showing only the files (or
directoryfiles ;) that have the right document format.

No more problems with files :)

Waiting for your contrary answer ;)

Friedrich

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