Proposal for a MIME mapping spec
pjp at osdl.org
Thu Jul 8 19:23:12 EEST 2004
Thomas Leonard wrote:
>On Thu, Jul 08, 2004 at 07:48:53AM -0700, Philip Peake wrote:
>>Alexander Larsson wrote:
>>>On Wed, 2004-07-07 at 23:46, Philip Peake wrote:
>>>>I would also like to add a plea to at least consider adding an
>>>>abstraction layer so that the on-disk hierarchy could be replaced by a
>>>>(possibly remote) database of some description (LDAP/RDBMS/etc).
>>It would also allow optimization of the config "database".
>>The Oregon primary (K-12) system uses a mixture of Linux and Windows
>>desktops, about 10,000 desktops in all. Students use whatever machine
>>they sit in front of. The user data/home directory is on a Samba server
>>(SMB mounts, to allow for Linux or Windows). The big problem is that of
>>scaling; at lesson change time all the students logout, move to another
>>classroom and login again -- and the fileservers melt down with the load
>>caused by the Linux desktops starting up.
>>They have tried the fastest disks they can find, and different disk
>>configurations - the best they can manage is to acheive something like
>>10 KDE startups or 14 Gnome startups per drive - then the disks are
>>saturated with random IO (seeking...), there is no problem with network
>>bandwidth or disk throughput, its simply the randomness of the IO.
>Interesting. Have you recorded which files are being accessed during
>startup? I would have thought that most data would be read from /usr,
>rather than from users' homes.
>Most of the above spec is about desktop files installed by applications,
>which won't normally be in $HOME, and I don't think looking up the user's
>preferred application to handle various types is something that will be
>done on login (even if you restore sessions, you will restore the same
>application that was running last time, not re-load the old documents with
>More generally, a configuration API is probably useful, but I don't think
>it will make any difference in this particular situation.
I wasn't the one that did the analysis, so I don't know exactly what the
But, since /usr is local on the machines, and it was $HOME (server) that
only during the startup phase, I think its reasonable to assume that its
the config files being
accessed that is the problem.
I know this discussion is really not about the config files, but being a
much smaller target,
and quite honestly, better defined, I thought this might be a suitable
place to start prodding
to see what the response would be to the ida of using an API rather than
a file format (with the
initial "backend" to the API supporting the current file format, of course).
Using an API could also have the advantage of pushing off detail like
(re)building the union-of-all
file into the API spec and letting the library deal with it each time an
update is made.
More information about the xdg