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