Are we getting close to release?

[jjross]

I want to test out CloudDrive but I'd like to be on a stable (RC?) version before giving it a go. Are we getting close to a release for this? How stable is the product?

 

It seems to have been in beta for a long time so I'm a little worried that it's buggy.

[zhup]

...

It seems to have been in beta for a long time so I'm a little worried that it's buggy.

 

I am also waiting for the stable version of CloudDrive but I have no concerns about the quality of the final product, because other products (DrivePool and Scanner) are very good and also support is at a high level.

[steffenmand]

Trust me... getting them to rush a release won't make things any better

But thank god they prefer to keep it in beta until the product really is stabil enough

 

However i must say that i have had data in the cloud with stablebit for more than a year now and i haven't lost any of it yet

[Christopher (Drashna)]

Well, we did feel it was getting close to an RC build... but the "Rate Limit Exceeded" issues we've been experiencing with Google Drive changes things. 

 

Right now, Alex (the Developer) is implementing a fairly major change that should significantly cut down on the number of API calls and prevent the Rate Limit Exceeded" issue. 

 

After that has been finished and tested, we should have another public beta or RC build out soon.  From there, we'll see.  

 

But we do want to get an RC and/or final build out in the near future, as well. 

[thnz]

Right now, Alex (the Developer) is implementing a fairly major change that should significantly cut down on the number of API calls and prevent the Rate Limit Exceeded" issue. 

 

Is this the local file ID database, or is there something else in the pipeline too?

[Christopher (Drashna)]

Is this the local file ID database, or is there something else in the pipeline too?

 

Yes, that is the major change. 

 

If your curious (I know *somebody* will be), the reason this is a major change is because it changes how files are queried for. 

Normally, we try to create a file.  If we don't get an error, the file is created on the provider. If it already exists, the file create errors out and hands us a File ID.   

(this also happens for each chunk during upload verification, as well, but not with the File ID database)

 

This effectively generates additional API calls that aren't strictly needed (and honestly, could be handled better).  But by maintaining the local database, it will significantly reduce the number of API calls that we need to make. 

 

Also, IIRC, part of the plan was to "sync" this database (which probably means uploading it along with the other disk data) so that "new" systems can use this database rather than starting from scratch. Again, significantly reducing the number of API calls used when mounting a drive on a new system. 

 

 

 

If you can't tell, the singular goal here is to reduce the number of API calls.   

 

And this doesn't just apply to Google Drive (though it's the primary provider).  It applies to Box, and I think DropBox (i'll have to double check with Alex).   But we're only implementing it for providers that use this sort of method for querying for file info. 

[jjross]

It seems to me it would make sense to do it for all providers. Is there a disadvantage for other providers if they were to use it?

[wid_sbdp]

Well, we did feel it was getting close to an RC build... but the "Rate Limit Exceeded" issues we've been experiencing with Google Drive changes things. 

 

Right now, Alex (the Developer) is implementing a fairly major change that should significantly cut down on the number of API calls and prevent the Rate Limit Exceeded" issue. 

 

After that has been finished and tested, we should have another public beta or RC build out soon.  From there, we'll see.  

 

But we do want to get an RC and/or final build out in the near future, as well. 

 

I don't know what you guys did between 730 and 742.. but I went from ~8-16mbs upload on Google Drive to like 250mbs. Much much much better.

[Christopher (Drashna)]

It seems to me it would make sense to do it for all providers. Is there a disadvantage for other providers if they were to use it?

 

Yes and no. Some providers are much better about it.  

Yes, I asked Alex about this actually.  Providers like Amazon S3, Microsoft Azure, and Google Cloud Storage are very optimized already, and won't benefit from this actually. 

 

However, for the providers that we feel would be, we are using it. 

 

I don't know what you guys did between 730 and 742.. but I went from ~8-16mbs upload on Google Drive to like 250mbs. Much much much better.

 

That's fantastic to hear!  Hopefully, many others experience this shift in speed as well. 

[thnz]

Not sure if you guys are aware, or if this will even be of benefit, but if you want to further optimize Google Drive, you can batch API requests together - with some limitations:

 

https://developers.google.com/drive/v2/web/batch

[Christopher (Drashna)]

I suspect that we are already making use of the API (or are unable to efficiently do so), but I'll let Alex know anyways.