[ 
https://issues.apache.org/jira/browse/JCLOUDS-639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14072307#comment-14072307
 ] 

Ignasi Barrera commented on JCLOUDS-639:
----------------------------------------

Also take into account that the {{JavaUrlHttpCommandExecutorService}} is used 
in the default HTTP driver, but jclouds also supports Apache HttpClient and 
OkHttp. Implementing this should be done at the "driver interface" level to 
make it driver agnostic, not only for the default one.

> Provide methods to get the progress of a running upload to a blobstore
> ----------------------------------------------------------------------
>
>                 Key: JCLOUDS-639
>                 URL: https://issues.apache.org/jira/browse/JCLOUDS-639
>             Project: jclouds
>          Issue Type: Improvement
>          Components: jclouds-blobstore
>    Affects Versions: 1.7.3
>         Environment: doesn't matter
>            Reporter: Peter
>
> The jclouds library should provide a way to get progress information about a 
> running upload to any blobstore (information like how many bytes where 
> already transferred and optionally average speed of the transfer).
> In _JavaUrlHttpCommandExecutorService_, the outputStream is already being 
> wrapped in a _CountingOutputStream_, but there is no way to call the 
> _getCount()_ method from outside the method. 
> There should be some way to access the current count of bytes already sent to 
> calculate the status of the upload. Additionally a way to get the average 
> speed would be nice, but I guess this is more optional because you can 
> calculate the speed on your own if you know how many bytes where already 
> transferred.
> Another option to solve this, is to provide access to provider-specific 
> features like the ProgressListener in the S3-API (see 
> http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/s3/model/ProgressListener.html),
>  but I guess that not all vendors have something similar in their APIs, 
> anyway the first approach would be a more generic one. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to