mapping [process|socket|...] to Filesystem

[Richard Kästner]

On Thursday 05 January 2006 12:12, Oliver Fromme wrote:
>
> Lou Kamenov <loukamenov at gmail.com> wrote:
>  > On 04/01/06, Oliver Fromme <olli at lurza.secnetix.de> wrote:
>  > [..]
>  >
>  > > It would be much easier to use HTTP instead of (ab)using
>  > > file system operations.  Just install an Apache web server
>  > > on your server machine and write a small CGI.  The Windows
>  > > clients can simply use a web browser to upload their data
>  > > to your CGI.  Then your CGI does whatever is necessary to
>  > > communicate with your black box, and sends the result back
>  > > to the client's web browser.
>  >
>  > representing different resources as files is not a new concept.. but
>  > rather an old one.  look at plan 9.
>
> Right.  Or look at devfs, procfs, fdescfs, portalfs etc.
>
> However, being able to represent resources or information
> via the file system does not necessarily mean that it is
> a particularly good idea to do so.  For example, I think
> that procfs does not really make much sense.  Especially
> Linux' procfs is a bad example of cramming too many things
> into the file system which do not belong there; it's just
> a big mess.  It might be "cool", it might be "easy to do,
> so lets do it", but it's horribly inefficient and does not
> make sense.
>
> Another important point is the common guideline that as few
> things as possible should be implemented in the kernel.
> The kernel should provide interfaces to the hardware and
> to essential kernel facilities, but everything else should
> happen in userland.  Richard is trying to implement a
> rather simple client-server mechanism to access a certain
> device on a server machine (I assume that there is already
> a driver for that device).  There is no sane reason to do
> that on file system level.  Handling it in userland is much
> more robust, easier to recover in case of problems, and
> easier to debug.

Again, it was one of my original questions: 'is my idea simply stupid ?'

And, yes, the communication via http is already working - nothing great.
It was simply the idea to go one step further: wrap some of functions into 
kind of 'file-transfer' from the client's point of view.

The idea (to me) still is tempting - but I will look at samba-vfs modules, 
possibly also fuse - which are clearly in userland.
(I fully agree with the common guideline: as few as possible in kernel !)

regards

Richard

-- 
Mit freundlichen Grüßen

Richard Kästner
EDV-Beratung
Woerthgasse 17
2500 Baden
Austria