Ok, good point. I guess it's safe to say that the most common case is
the local case so an explicit file name makes sense.
>[A file interface] is simply too limiting for network computing.
>Data-mining applications need to work with local disk and remote I/O
>servers in the same run.
I agree. However, can we be more specific? What kind of remote I/O
servers do we want to support? What protocols do these servers use?
Can info args support these protocols?
>Try asking the management at your site to mount disks at Nasa Ames.
>Then try asking Ames for permission ...
Ok. Parkson, can I mount disks at Ames? Probably not. If not, what do
we need to do to access data at Ames? Are info args sufficient in this
case?
>Further, consider trying to mount a remote I/O server. The inode
>paradigm breaks down at this point.
I agree. However, the vfs-vnode paradigm *might* be sufficient. I
think it is sufficient if we want a file interface. Obviously, you want
more than that.
>Well, I thought I was a person ... Others at the meeting are checking
>with their {\em users}.
I agree that you are a person. :) Seriously, I was actually asking the
``others'' for a response.