[MPlayer-dev-eng] [patch] prefer ALSA over OSS

[Attila Kinali]

On Fri, 4 May 2007 16:39:14 +0400
Vladimir Mosgalin <mosgalin at VM10124.spb.edu> wrote:

>  On 2007.05.04 at 13:57:57 +0200, Attila Kinali wrote next:
> 
> > Please tell me one reason why anyone want to use gnome-vfs
> > in a normal unixish application? 
> 
> So you can open file over network directly from file->open dialog. Most
> application don't have such dialogs, therefore they don't need
> things like gnome-vfs. However, some do.

Brrr... There are a few gtk apps i need. And with every update
of gtk, the file choose dialog gets worse and worse. It has come
to a state where it is hardly usable and i really think i should
one day sit down and write a wrapper lib so that i get a nice
file choose back again.

And just for the record. 99% of the programs i use, do not have
a file->open dialog. And even of those that have, i never felt
the need to have any fancy non-local file retrival/storing.
Either i have the file on one of my mounted filesytems or
there is scp/wget. (can you feel the breeze of unixish behavior?
the wisper, that a tool should do only one thing and that very good?
that the tools should be able to interact with each other and be chainable?)
 
> For console application, there was very nice solution called avfs; could
> be used for easily accessing archives and ssh/ftp/http resources from
> any application. Unfortunately, it's dead. It could be reimplemented on
> top of fuse, but this was never done.
> 
> > The gnome-vfs API is IMHO so much overcomplicated that noone
> > in his right mind would want to touch it (unless there is a
> > very special requirement which 99.999% of the applications
> > do not have).
> 
> Sure, I don't suggest anyone to use it. I just meant that some vfs
> wrapper solutions are useful even for regular input/output.
> Clearly some api which looks very much like original posix api should be
> used, maybe even 99% compatible one. 

If it looks like the POSIX/BSD api, then there is no need to
use it at all. Or do you need plastic covers around your spoons,
forks and knives that look like spoons, forks and knives to be
able to eat? Or are you afraid to hurt yourself if you'd touch
real metal?

This reminds me of one of the quotes from Tobias Oetiker:

---(from http://www.amiv.ethz.ch/forum.php?submenu=dienste)
"Es ist mit der Situation zu vergleichen, wenn du neben dem Alpamare
ein aufblasbares Kinder-Bad aufstellst und den Leuten sagst sie
sollen doch zu dir kommen, denn das Wasser in deinem Becken sei
2 grad wärmer und ertrinken könne man da auch nicht ...

Ich finde die Leute sollen Schwimmen lernen ..."
---
( "It is comparable with the situation, if you'd put a small
childrens pool at the Alpamara(big spa in Switzerland) and
tell people that the water in your pool is 2 degrees warmer
and they couldn't drown in there....

I think people should learn swimming....")

> But it would work faster and better
> if implemented as LD_PRELOADed library or regular library comparing to
> what fuse offers. And that fuse exists because no one thought about and
> on one needed vfs in userspace when unix was created; otherwise, there
> would be no need for fuse now. And there is no reason to repeat this
> history with audio - library aproach already works better. 

I still don't get why you'd need something like this? Either
handling remote filesystems is completely transparent in the
Plan9 way or it should made obvious to the user. Putting a badly
designed wrapper around it (even fuse) isn't a solution, but just
papering over problems without really understanding the issue.

Somehow you sound like the people who permanently advice others
to use XML, because it's plain text, portable and there are lots
of libraries to handle it... No matter how wrong XML might be
be for the problem at hand.

			Attila Kinali

-- 
Praised are the Fountains of Shelieth, the silver harp of the waters,
But blest in my name forever this stream that stanched my thirst!
                         -- Deed of Morred