[
https://issues.apache.org/jira/browse/THRIFT-2287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13865775#comment-13865775
]
Jens Geyer commented on THRIFT-2287:
------------------------------------
[~wayne.rasmuss],
{quote}
Sometimes tasks take a long time. For example doing a mirror of a directory
that is gigabytes in size. Waiting until the process is complete to get results
is not very friendly. {quote}
I'm not convinced by that example. Let's assume, you want to copy the same
giant file across your LAN. What would you do to keep the UI alive? Depending
on your environment, you either grab the telephone and call Microsoft and
politely ask for changing the CopyFile() API, or you grab the Linux kernel
sources and modify what's necessary to do that on your own. Right?
Of course not. Keeping the UI alive is one thing, *putting time-consuming
activities into a background thread* is another thing.
The only use case I see is for creating some kind of push notifications.
Altough there are ways to achieve that with Thrift, a built-in support would
still be nice to have. But that's my personal opinion.
~Yes, I know that things like asynchronous or overlapped I/O exist. You are
free to replace the long running operation in my example with something else~
> Allow services as parameters
> ----------------------------
>
> Key: THRIFT-2287
> URL: https://issues.apache.org/jira/browse/THRIFT-2287
> Project: Thrift
> Issue Type: Brainstorming
> Reporter: Wayne Rasmuss
> Priority: Minor
>
> What about allowing services as parameters to thrift methods? This would be
> useful for returning interim results, logging and probably other use cases.
> At first I thought, nah that can't work, but I thought about it more and it
> seems maybe it could. Though I know little of Thrift's internals.
> When the service parameter was serialized only its connection information
> would be sent. Additional data may need to be provided to the service (true
> host name etc.) That would be fine with me.
> It seems like both sides should have most of the features they need for this.
> It would probably be a requirement that the service was started, bound etc
> before being passed a a parameter.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
