>>> For now, every app with this problem has to implement something like
>>> a growable (and hopefully shrinkable) filesystem within a file.
>>> Apps can add a block mapping layer complete with triple-indirect
>>> blocks, or they can copy around huge amounts of data and update
>>> document references as needed.
>>
>> The point being that they *do* that. Each has its own bloody format. Each
>> will *have* to carry that code around, unless you will manage to push
>> every blasted thing into the kernels. Yup, plural. Linux is not the only
>> UNIX.
> Linux is not UNIX(R) at all. Linux is a hot new operating system
> designed for the next century^H^H^H^H^H^H^H38 years. UNIX(R) is dead.
Good joke. You can be sure that ANY non-portable solution will not be used
neither by KDE nor by GNOME. And if want to use this "hot new operation system"
on desktop (and server does not need compound documents support very much :-)
without KDE and without GNOME... Hmm... Good luck :-E
>> Good luck doing that. If you are going to invent a new uniform
>> scheme - fine, go ahead, implement it as filesystem and I will write a
>> loopback-mount-on-the-fly. Oh, and don't forget to make them switch to new
>> format. Deal?
> That is one way to implement the API, but it won't let the document
> share allocation and namespace support with the filesystem.
> You still end up going through two filesystem(-like) layers.
Why ?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/