[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:       Brad Hards <bhards () bigpond ! net ! au>
Date:       2002-05-15 11:37:03
[Download RAW message or body]

On Wed, 15 May 2002 10:15, Steven D'Aprano wrote:
> It should be applicable to any file, regardless of file format. It
> should be totally independent of the application used to generate it,
> or view it. It should be transparent to apps that don't understand it,
> but those apps should not break the link between data and metadata.
This is an extremely difficult problem. Even if you have kernel support, tools 
that implement basic operations need to be aware, and copying a file to a DOS 
floppy, FTPing it, or the like will break unless it is a single file (eg in 
the zip archive).

> This is why, ultimately, no metadata system without kernel support can
> ever be complete.
This is a big ask too. Remember that KDE runs on more than just Linux. 
Consider Solaris and Tru64, plus the BSDs.

> This is not to suggest that partial solutions aren't helpful. Koffice
> files already include metadata such as Author, and MS Word includes
> much more extensive metadata. It may be very useful for Konqueror to
> have support for Koffice metadata, and I don't intend to dismiss that
> idea at all.
Getting this working would solve most of the problems of interest.

> *But* there are lots of things that you can do with metadata on the
> file level, that you may want to do to non-XML files such as text,
> source code, jpeg, etc etc etc. For instance, you might want to
> associate a general purpose Comment metadata field to *any* file. And a
> generic metadata system should allow users to create and use their own
> metadata fields, and not just be limited to the ones the app developer
> thinks you need.
I don't know how to solve this. The only thing I can come up with is to 
encapsulate the file.

> Again, I stress that without kernel support, any solution to this
> problem will be a hack. It may break as soon as you move the file using
> non-KDE methods. But so long as metadata is only inessential (but
> useful) data, and so long as people understand the limitations, I still
> think its worthwhile.
It is not good to force people into using KDE methods. Backups, cross platform 
transfers, even just a mix of some users with Gnome (+KOffice) and KDE 
(+KOffice) could break things in irritating and obscure ways. I still think 
you _have_ to embed the metadata in the file.


> To my way of thinking, metadata is a USEFUL thing, not an ESSENTIAL
> thing. So if we have to go through one or two less-than-perfect
> inelegant hacks in order to demonstrate the usefulness of the concept
> enough to get the kernel support needed for a perfect implementation,
> then so be it.
I agree with this, but it is critical that it works consistently and 
predictably (ie you don't get random breakage, and it works on any KDE 
platform).

-- 
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.

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