[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 20:47:49
[Download RAW message or body]

"Aaron J. Seigo" schrieb:
> 
> wow, this thread has been going on for a long time... i've refrained from
> entering the conversation up to this point but .....

> On May 19, 2002 08:23 am, Friedrich W. H. Kossebau wrote:
> > 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).
> 
> .... have you used konqueror in kde3? there is a thing called KFileMetaInfo.
> it is a plugin-based architecture that allows access to file metadata in both
> view and edit modes.

I'm still resting with KDE 2.2.2, hopefully changing to 3.0.1 soon.  
But... ;)
I have heard of KMetaFileInfo. As much as I understood, it offers a
quick read/write access to metainfo for those mimetypes/formats that
have some (and there exists a specific KMetaFileInfo implementation). So
this is better than nothing but still limited. 

And this was not the point I wanted to make...

> for example on mp3s ... if you mouse over an mp3 you get to see its bitrate,
> the id3 tags, comments, etc ... if you RMB on it and look at properties you
> can edit the comments and band/album info, etc...
> 
> and it does it w/out confusing the concepts of "file access", "file
> organization" and "relavant (aka meta-)info"...
> 
> try it out, i think you might like it...

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.

Think of a gimp file where a gimp-browser-slave lets you have direct
access to the layers: gimp:/home/kossebau/images/test.xcf/layers/
will show in the file view each layer as a file with mimetyp
image/x-xcf-layer
Or a font-brwoser: truetype:/home/kossebau/fonts/times/bold will list
all letters each as a file of mimetyp image/x-svg (or whatever vector
format that is or can be converted to)
Or ps:/home/kossebau/thesis/doc.ps/ will list all pages...

These all should be examples for the overcome of the actual file formats
that encapsulate further structure. 

On the other hand there are examples of content spreaded over different
files:
1. Have you ever worked with Framemaker (R) or Pagemaker (R)? The text
could be in different files outside of the main file itself. So one
could easily edit/copy the text outside of pagemaker with the editor of
one's choice. Same with the images. 
2. Take KDevelop. All software project are splitted into a buch of files
whose content makes only sense as a whole. Still you can treat them all
individually. 

So metadata is simply another file/stream/directory of a
file/stream/directory. That's what David.Golden said IIUC, that is where
I agree and which I wanted to underline with further thoughts.

Still this doesn't solve the problem of integrating a metadata system
into actual filesystems... :(

Friedrich

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