Fwd: Re: A common VFS and a Common conf-system [Part II]

[gtg990h at mail.gatech.edu]

> Using an example:
> A webbrowser gets an URL like http//host&path/file?query
> It uses a convenience function to transform it into a system specific path,
> on
> Unix likely something like
> /dvfs/http/host/path/file?query
> and then use open() to open that "file"
> The kernel would see that it has dvfs mounted on /dvfs and relay the open to
> the dvfs "filesystem"., which would pass the request to the D-VFS daemon.
> The daemon decodes the "filename" into its URL form, creates a socket and
> returns when its open() returns.

It would work more like this:

Web browser gets a URI.
It calls the equivalent of open() in the D-VFS API, and passes it the URI.
The D-VFS library sends the open request to the D-VFS daemon.
The D-VFS daemon checks to see if the parent is already mounted, and if not, has
the kernel mount it using something like httpfs.
The D-VFS daemon calls open() on the resulting path, associating the D-VFS
"file" object with the underlying fd.
The D-VFS library uses whatever D-BUS protocol gets defined, and the D-VFS
daemon implements those actions by reading/writing to the fd.

The nice thing about this approach is that if the user now wants to use a CLI
app on the file, they can copy & paste the URI into their terminal, and it "Just
Works".

> I am not very experienced with the native API regarding non blocking IO.
> Can an application open a file non-blocking and then use select/poll on it
> without loosing quite some performance?

It depends on the platform. BSD kqueues, Solars event ports, and Windows I/O
completon ports, provide for high-performance notification of AIO transactons.
I'd presume epoll would (or could) be able to do something similar.