[
https://issues.apache.org/jira/browse/HADOOP-4952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12750771#action_12750771
]
Sanjay Radia commented on HADOOP-4952:
--------------------------------------
> * There is a FileContext in the metrics package too, so perhaps we should
> rename this.
Hmm. didn't know that. FileContext is a very appropriate term since it is
context for resolving file names. The term context is used heavily in naming
literature for that purpose. In our discussion, folks got the whole concept of
what I was trying to do as soon as I changed the class name from Files to
FileContext. I am tempted to leave it as is since it is in a different
package. I don't want to call it a FSContext since it s not a context for
FileSystems. Strictly specking it is context for file names. Perhaps I should
call it PathContext or FileNameContext. Or perhaps rename the metrics one
since it is an internal class.? Do you have preference in one of the options I
suggested? Or another suggestion.
> * What's the util() method for? Why are its methods not first-class
> methods of the interface. Seems confusing to users.
The distinction is the methods in util are merely library methods build over
the other basic one.
Original plan was to move all library methods to FSUtil. But that forced
passing an additional parameter (fc) to each of the FSUtil methods. Many
disliked that. What I did was a compromise. I don't feel strongly about this
either way.
> Improved files system interface for the application writer.
> -----------------------------------------------------------
>
> Key: HADOOP-4952
> URL: https://issues.apache.org/jira/browse/HADOOP-4952
> Project: Hadoop Common
> Issue Type: Improvement
> Affects Versions: 0.21.0
> Reporter: Sanjay Radia
> Assignee: Sanjay Radia
> Attachments: FileContext3.patch, FileContext5.patch,
> FileContext6.patch, FileContext7.patch, Files.java, Files.java,
> FilesContext1.patch, FilesContext2.patch
>
>
> Currently the FIleSystem interface serves two purposes:
> - an application writer's interface for using the Hadoop file system
> - a file system implementer's interface (e.g. hdfs, local file system, kfs,
> etc)
> This Jira proposes that we provide a simpler interfaces for the application
> writer and leave the FilsSystem interface for the implementer of a
> filesystem.
> - Filesystem interface has a confusing set of methods for the application
> writer
> - We could make it easier to take advantage of the URI file naming
> ** Current approach is to get FileSystem instance by supplying the URI and
> then access that name space. It is consistent for the FileSystem instance to
> not accept URIs for other schemes, but we can do better.
> ** The special copyFromLocalFIle can be generalized as a copyFile where the
> src or target can be generalized to any URI, including the local one.
> ** The proposed scheme (below) simplifies this.
> - The client side config can be simplified.
> ** New config() by default uses the default config. Since this is the common
> usage pattern, one should not need to always pass the config as a parameter
> when accessing the file system.
> -
> ** It does not handle multiple file systems too well. Today a site.xml is
> derived from a single Hadoop cluster. This does not make sense for multiple
> Hadoop clusters which may have different defaults.
> ** Further one should need very little to configure the client side:
> *** Default files system.
> *** Block size
> *** Replication factor
> *** Scheme to class mapping
> ** It should be possible to take Blocksize and replication factors defaults
> from the target file system, rather then the client size config. I am not
> suggesting we don't allow setting client side defaults, but most clients do
> not care and would find it simpler to take the defaults for their systems
> from the target file system.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
