[
https://issues.apache.org/jira/browse/HADOOP-12910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15323118#comment-15323118
]
stack commented on HADOOP-12910:
--------------------------------
bq. No, they are the same API. Branch-2 is a simplified version of trunk.
So they are not the same then, one is a 'simplified version'.
I think I can see where you are coming from with your thinking that
chaining/callbacks are nonessential and with your fixation on 90s-era AWT-style
APIs registering listeners (that launches rockets). I was just hoping we could
learn from the past rather than repeat it. I was also hoping that downstreamers
didn't have to perform contortions or rely on a 'library' to fill in missing,
essential pieces.
On the latter suggestions, IMO, the pro for ListenableFuture -- that we'd have
same API in branch-2 and in branch-3 -- outweighs all other concerns. Same for
Deferred which seems nicer but w/ same cons. CompletableFuture is a large
undertaking and going by your diggings, seems hard to do w/ our jdk8. Thanks.
> Add new FileSystem API to support asynchronous method calls
> -----------------------------------------------------------
>
> Key: HADOOP-12910
> URL: https://issues.apache.org/jira/browse/HADOOP-12910
> Project: Hadoop Common
> Issue Type: New Feature
> Components: fs
> Reporter: Tsz Wo Nicholas Sze
> Assignee: Xiaobing Zhou
> Attachments: HADOOP-12910-HDFS-9924.000.patch,
> HADOOP-12910-HDFS-9924.001.patch, HADOOP-12910-HDFS-9924.002.patch
>
>
> Add a new API, namely FutureFileSystem (or AsynchronousFileSystem, if it is a
> better name). All the APIs in FutureFileSystem are the same as FileSystem
> except that the return type is wrapped by Future, e.g.
> {code}
> //FileSystem
> public boolean rename(Path src, Path dst) throws IOException;
> //FutureFileSystem
> public Future<Boolean> rename(Path src, Path dst) throws IOException;
> {code}
> Note that FutureFileSystem does not extend FileSystem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
