Request: Google Drive

[benjam-es]

Would it be worth adding google drive as an option?

[frankdejonge]

@benjam-es it would indeed, it's on my mental roadmap.

[renege]

👍

[nojacko]

+1

Would have made migrating Dropbox to Drive last week so much simpler!

[acelaya]

@FrenkyNet I just forked this repository in order to make a Google Drive adapter. I started to work on it but it looks like a harder task than I thought.
The first problem is that the Google PHP SDK supports PHP 5.2, so it's not very confortable to work with it, but I can deal with that.

The main problem is that Google Drive allows duplicated filenames, so absolute paths are not unique. As for this you need to work with IDs. Each file and folder has a unique ID.
Also, any file or folder can be in multiple locations at once, having more than one direct parent.

This makes it very inefficient to work with the flysystem API, which works with paths, because you always need to recursively walk over the files tree to convert a path into a Google Drive ID or vice versa. With long paths that means many HTTP requests.

I've seen the Dropbox API doesn't have this problem, because it uses unique paths to identify files and folders.

I could continue anyway, what do you think.

[frankdejonge]

@acelaya I've hit that roadblock too. I've though about two solutions. First one is create index files in on the drive. The other one is a required persistent cache for that adapter. This way the index can be built once, refreshed if needed. This would have to map the ID's from google drive to the paths. This still doesn't tackle the unique path issue. A case could be made for just not supporting that. Flysystem is an abstraction with a set of guidelines, both for the package itself as for what kind of adapters can be used. Some concepts are not portable, of which this is one.

[acelaya]

@FrenkyNet I was also thinking about not supporting the duplicated paths. It's a very concrete feature that most of the users won't need.
Having an index to fix the other problem is not a bad idea, but a required persistent cache could make this adapter "too hard" to use compared with any of the others.

I think I'm going to work with a remote index file that is read once the adapter is created and refreshed every time the file structure changes. Maybe I set a persistent cache as an optional argument too.

Also, a remotely shared index file has another problem. Concurrent updates could make it inconsistent, but I think it's a good approach for a first version.

[frankdejonge]

@acelaya if you could, make the index a separate class with an interface so I (or somebody else) can create the other implementation too.

[acelaya]

Perfect!

[Jaspur]

👍

[garygreen]

Any news on this? I would like to see the initial implementation and add it to my site :-)

[garygreen]

@acelaya also about the implementation. I noticed also that you can have the same 'filename' on drive but with a different unique id. Would an easier implementation be (instead of keeping an index, which is a good idea but possibly not required with this)... when adding a file, check to see if another file with the same title exists on drive, if so, delete the one from drive then upload the file. That way only one copy of that file will ever exist. Not sure if this is possible or a good idea but just throwing it out there :-)

[acelaya]

@garygreen Yes, that would be an option, but that doesn't solve the index problem.
The index maps full routes to its GDrive's ID.
For example, If I tell the adapter I want to delete the file /foo/bar/baz/file.zip, GDrive API has no way to do that since it identifies files and folders by a unique ID rather than doing it by its path like Dropbox API does.
For that reason I have to fetch the root folder and find the foo folder. If exists I have to get its ID, list its contents and find the folder bar. Again, if exists, list its contents and find the baz folder, and finally find the file file.zip and get its ID to delete it.
Those are 5 HTTP requests for an operation that looks easy at a first sight. Imagine if the path is longer. Working like that would make this adapter to be very slow.
Also, I'm always assuming there's no duplicated files. If the foo folder has two bar nested folders and the path is not in the first one, the search could fail or I would have to check both of them, which means more HTTP requests.

That's why @FrenkyNet suggested to have an index, but I can't find the correct implementation for it.
Making a full index the first time is way too slow. Creating the index as needed is faster, but it slows down each request that has to add contents to it.
Also, the index could be outdated at any moment by requests from third party sources.

The Google Drive's adapter is tricky. I would like to make this contribution, since this library has been very useful to me, but I started to work on this feature a few weeks ago and suddenly other projects kept me away from it, and it needs time to get done.
Any help would be very appreciated, not just on writing code, but on finding a good solution on the index subject.

[garygreen]

@acelaya I believe google refers to the file as 'title' could you not use the search parameters api for the title (it may return multiple results, but as suggested we could only support having one title/path): https://developers.google.com/drive/web/search-parameters

[acelaya]

I could assume a file with the same title won't be more than once in the same folder, but I can't assume it won't be more than once in multiple folders.
If I'm not mistaken, the search API will look into every folder so I won't be able to know wich one is the file I'm looking for. I could look into the parents, but that will make me make recursive requests, which leads me to the very first problem.

[sagikazarmark]

Any progress?

[JC5]

The Google Storage API is very similar to the Google Drive API. Might be something to consider.

[jabbon]

I would be nice support for Google Cloud Storage +1

[bogdanghervan]

+1 for a Google Cloud Storage adapter.

[sagikazarmark]

Make no mistake: Google Cloud Storage is not the same as Google Drive. (And the issue is about Google Drive)

[bogdanghervan]

No mistake made. In fact I went ahead and added a separate issue for GCS, #448.

[sagikazarmark]

Great, you are not the first mentioning GCS instead of GD.

[alimuzaffarkhan]

I haven't read the Google Drive API yet but Google Drive doesn't do anything special than any other Unix/Linux based system. We can have Files with same names in different folders on any filesystem as well, also we can have same file in multiple folders using links.

[Garbee]

It isn't anything like traversing a Linux system. That is a gross
understatement of what is required.
On Mar 20, 2015 1:17 AM, "Ali Muzaffar Khan" [email protected]
wrote:

I haven't read the Google Drive API yet but Google Drive doesn't do
anything special than any other Unix/Linux based system. We can have Files
with same names in different folders on any filesystem as well, also we can
have same file in multiple folders using links.

—
Reply to this email directly or view it on GitHub
#192 (comment)
.

[dimaip]

Any updates on Google Drive support?

[matthewbaggett]

You're not the only one waiting out with wishful hopes for Google Drive
support.

Edit: thats what I get for replying with an email.

[alexw23]

👍

[jmcbee]

👍 Woot woot!

[alexw23]

After fiddling around a little I found that the Google Drive API follows suit with Box and OneDrive, so I actually think the abstraction layer needs to be thought out and improved to support these standards, through a library of some sort. There needs to be more traversal implementations to handle these in a consistent manner.

I disagree with the issue of multiple http calls as really the GDrive API is super quick and most file system tasks are happening in the backend anyway so they are not time sensitive. And I think indexes does not support a stateless implementation.

[alexw23]

I've uploaded my hacky implementation here - looking for collaborators to help continue this
https://github.com/ignited/flysystem-google-drive

[nojacko]

Nice one @alexw23. If I get any spare time I'll try to help out. Really want this one.

[asivaneswaran]

Hey guys, any news on this?

[alexw23]

Still looking for help on https://github.com/ignited/flysystem-google-drive

[JayBizzle]

@alexw23 where do you need help? What's the status of your implementation? Any particular issues?

[gpilla]

+1

[gpilla]

@alexw23 I also offer my help...

[alexw23]

See ignited/flysystem-google-drive#1

[ghost]

I guess this is not happening? I would contribute but my PHP/lib knowledge is very limited and the Google API files are a complete mess.

[frankdejonge]

@Raydric I'd love to be able to work with an sdk that made sense for this case, but there isn't which makes this task to big to tackle, as many have tried and unfortunately failed.

[ghost]

@frankdejonge I understand, thanks anyway! Their documentation is huge (but not complete) and weird. Two hours in and it's already driving me crazy.

[frankdejonge]

@Raydric many times have I though about doing this, but I keep getting lost and it's just too frustrating having to go through it.

[frankdejonge]

In light of this, I'm closing this issue.

[alexw23]

I've already implemented this and have it working fine. https://github.com/ignited/flysystem-google-drive, we are already using the implemented methods in production and haven't had an issue so far. There is still work to be done on the rest of the methods. (ignited/flysystem-google-drive#1). I don't know why it needs to be as complicated as you make it out to be.

[garygreen]

@frankdejonge I'd recommend to keep it open, at least for others to see there is a desire and have a stab at it.

[alexw23]

Yeah - if someone wants to submit a PR for any of them methods please do. We can get it wrapped up in no time. If everyone on this thread spent 20 minutes we would be done :) 👍

[touqeershafi]

Any Progress on Google Drive Integration ?

[wordskill]

I would like to add some recent information that highlights how useful this functionality would be. Of course, that does not make it any easier to implement but does suggest that the reward might be worth the struggle.

Until recently, Google Apps for Work (at $10 per month) only gave unlimited Google Drive storage to organizations with 5 or more users, anyone with 4 or less users was capped at 1TB.

Now that 1TB cap appears to have been unofficially removed and even single-user accounts like mine have been given unlimited storage, allowing me to use my Google Drive to permanently archive a massive number of website and system backups without any problems at all.

As seven million businesses already use Google Apps for their custom domain email addresses and other apps, it seems likely that some would prefer to use this free unlimited storage rather than pay-per-use S3 storage or limited Dropbox storage.

In non-first world countries, the price of the 30GB Apps for Work tier has been reduced from $5 to $3. This aggressive and highly-targeted pricing suggests that Google is deadly serious about dominating the paid storage market worldwide.

The free Google Apps for Education has already included unlimited Google Drive storage for every user since September 2014.

Also, all Google accounts are entitled to a free 15GB Google Drive. I don't know how many Google accounts exist but there are roughly a billion Gmail accounts.

[nao-pon]

I'm doing work in progress in https://github.com/nao-pon/flysystem-google-drive .

[progsmile]

👍