[MPlayer-dev-eng] Added new protocol smb://

[Gábor Lénárt]

On Sat, Oct 05, 2002 at 10:31:43PM +0200, Arpi wrote:
> Hi,
> 
> > Sorry if I miss something but I would like to ask: why?
> > In general, UNIX is about modularity. Thus since Linux already supports
> > mounting SMB shares why do you need this? It's like you include full NFS
> > client in user space just because you don't like mounting NFS exported
> > directory first, than use that. It would turn into VERY complex and large
> > code to include several (networked) filesystem direct support into mplayer
> > while the certain fs is already supported by Linux (kernel).
> 
> I have to disagree.

I have too :)

> Since you can mount FTP shares (ftpfs), why do you need an FTP client? :)
> Or why do you use wget to get a file from a given url, instead of mounting,
> cp, umount it?

But smbfs is part of standard "official" kernel, while ftpfs is not.
So virtualy almost everybody can use smbfs (imho kernels of distributions
have this compiled in), while ftpfs needs some patching, and AFAIK ftpfs
is not well maintained and has some problems.

So OK, maybe you're right but it's the SAME when we're speaking about NFS.
So if you're right here, someone should implement a user space NFS client
inside mplayer just for avoiding mounts?

What is wrong about mounting file systems? Even Microsoft started to move
towards that, though they're naming it "filesystem reparse point" or something
similar.

> > Also, if mounting is not good for you, there is a library (however I forgot
> > its name) which can be forced to use with LD PRELOAD and it will handle
> > some libc file functions on its own to allow to use //machine/share ... etc
> > like "paths" as you expect like native "unix paths" without a single line
> > changed in the source of the application.
> hmm. it sounds really more unix-friendly :)

Not for me :) But if somebody wants this, you don't need to hack up source
of mplayer just for this functionality. 

- Gábor (larta'H)