hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Baldeschwieler <eri...@yahoo-inc.com>
Subject Re: [jira] Created: (HADOOP-713) dfs list operation is too expensive
Date Tue, 21 Nov 2006 04:22:11 GMT
I've got to disagree with that.  It's simply not responsible to add  
features that are not going to be easy to support as we near our  
medium term size targets.  Especially not in a central interface.   
I'd welcome anyone who wants to contribute an expanded viewer that  
lists recursive sizes, guess dates and does other cool things.

I'd just not support adding it to the project core or into the  
primary HDFS browse API that is built into all name and data nodes.   
We want these daemons to be simple, fast and stable.

That would commit us to either:

a) Taking a feature away later to ease scaling the system.  Always  
hard to do.

b) Doing a lot of extra engineering to make this fast later, even  
though it is not central to the framework.

On Nov 15, 2006, at 11:29 PM, Arkady Borkovsky wrote:

> Eric,
> there is some difference between the foundation components and user  
> facing components like UI.
> While foundation is expected to be stable and compatible from  
> release to release,
> UI is expected to evolve, continuously becoming more and more  
> useful and powerful, and providing as much of useful functionality  
> at any given time as possible.  The specific issue discussed in  
> this thread (what datums to show in directory listing for a  
> subdirectory) is pretty minor -- the more the better, commensurate  
> with resources, and nothing too misleading is the answer,
> But as the matter of design principles, user facing components have  
> different nature than the infrastructure.  There can be no "time  
> bomb" in the UI.
> -- ab

View raw message