Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-issues@hadoop.apache.org
Message-ID: <169173845.1251852872939.JavaMail.jira@brutus>
Date: Tue, 1 Sep 2009 17:54:32 -0700 (PDT)
From: "Sanjay Radia (JIRA)" <jira@apache.org>
To: common-issues@hadoop.apache.org
Subject: [jira] Commented: (HADOOP-6223) New improved FileSystem interface
 for those implementing new files systems.
In-Reply-To: <9646781.1251678812835.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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 writer.
> 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.