hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sanjay Radia (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HADOOP-6223) New improved FileSystem interface for those implementing new files systems.
Date Wed, 02 Sep 2009 00:54:32 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-6223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12750209#action_12750209

Sanjay Radia commented on HADOOP-6223:

Doug says:
>I don't see how this is simpler. It breaks existing users and implementations just to
have a different name.
I am confused here. If FileSystem or parts are to be deprecated then aren't you breaking existing
users anyway?
Were you planning to allow apps to use FileContext or FileSystem forever - ie both API are
for application use?
I was proposing that new FileSystem is for implementing file systems and FileContext is for
application use. (See Jira description).
Some of the method names of the old FileSystem and new FileSystem may accidentally  match
but their semantics will be different:
For example old FileSystem understands / and wd. I am proposing that the new FileSystem does
not - new FileSystem will process only fully qualified names within its FileSystem; FileContext
understand /, wd.
Same class name and same method signature but different semantics across releases is confusing
to users. 

I suspect we don't agree of the goal of this Jira as stated in the description. If you believe
that the goal is to provide 2 layers (FileContext and FileSystem)
one more convenient  than the other but leave many of the methods in the old FileSystem compatible
then I can understand why you would want to leave 
the class name the same and are surprised that I am making such a stupid suggestion to change
the class name.


Agree with Arun about the danger of re-purposing the same full class name. Either the package
name or class name should change by convention.
Although I  have a preference for leaving in the fs package and calling it FileSystemBase
or AbstractFileSystem, I can live with Arun's proposal (vfs.FileSystem).
I assume that the package name vfs is derived from the unix "vfs" layer for implementing new
filesystems in the Kernel.

Also changing the name has the advantage that we can immediately create the new class (vfs.FileSystem)
and change new FileContext to use it. 
My plan was to make fs.FileSystem a subclass of  vfs.FileSystem, etc as soon as possible.

> New improved FileSystem interface for those implementing new files systems.
> ---------------------------------------------------------------------------
>                 Key: HADOOP-6223
>                 URL: https://issues.apache.org/jira/browse/HADOOP-6223
>             Project: Hadoop Common
>          Issue Type: Sub-task
>            Reporter: Sanjay Radia
> The FileContext API (HADOOP-4952) provides an improved interface for the application
> This lets us simplify the FileSystem API since it will no longer need to deal with notions
of default filesystem [ / ],  wd, and config
> defaults for blocksize, replication factor etc. Further it will not need the many overloaded
methods for create() and open() since
> the FileContext API provides that convenience.
> The FileSystem API can be simplified and can now be restricted to those implementing
new file systems.
> This jira proposes that we create new file system API,  and deprecate FileSystem API
after a few releases.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message