Re: Moving away from app-centric mimetypes (e.g. kword)
Allan Sandfeld Jensen <[email protected]> Thu, 16 May 2002 02:09:42 +0200
| Newsgroups | gmane.comp.kde.look |
|---|---|
| Organization | One2one Networks A/S |
| Message-ID | <[email protected]> |
On Wednesday 15 May 2002 23:17, Brad Hards wrote: > The first part of this comes across as condescending. > > You might be able to do a userspace filesystem, and mount it using the > loopback interface, but it would still need some kernel support. > > In any case, we can implement it without a full virtual filesystem, and get > most of the functionality required. In any case, it would allow the > userspace presentation (which should be mostly indpendent of the underlying > implementation) to be determined. That is a more useful thing to be > discussing in any case (especially on a look'n'feel list) > Well, my basic argument is that filesystems are not offered directly by the kernel. They are offered by libraries that just happen to use the kernel on operating systems with a monolithic kernel. If we want extra features like extended attributes, we are already breaking or at least extending the posix filesystem interface, and migth as well make a new and better one. If we have such a new interface and it either was backwards compatible or it becomes defacto standard, we have what we want; a transparent extension to already existing filesystems. Ofcouse there are advantages of placing metadata-support in the kernel, most notable instant transparancy. The disadvantage is that it would take a decade before we could even assume most linux' installation used such a FS, (and before that possible longer to even convince the kernel-hackers that such a feature belongs in the kernel. ) To place the metadata in separate files in a directory is not much different from wrapping the files, it will look odd to 3rdparty applications and metadata would not survive to move through such applications. The best thing I guess, would be to implement something simple with a welldefined standard. It might also be wise to make it look like something independ from KDE, that we just "happen" to like and thus implement. Hopefully other non-KDE applications will then implement the same standard.