Re: OneDrive backend



Hi Vilem,

2018-05-22 15:33 GMT+02:00 Vilém Hořínek <vilem horinek hotmail com>:
Ondrej Holy píše v Út 22. 05. 2018 v 14:09 +0200:
Hi,

in that case, the new backend is a definitely good way. I don't know much about OneDrive, but hope that the handling will be a little bit easier than in google case... Rishi, don't you have any comments apart from the one on that bug report?

See what problems are with path handling in google backend:

I looked into that and if I understand it correctly the whole problem is the possibility of having two files with the same name in one folder. On OneDrive, though this wouldn't be a problem, since OneDrive doesn't allow this, so the backend wouldn't need to expose path composed from ID, but it could be the actual path in the storage.

I think that there was also another intention. The file has still the same ID regardless of the actual file name, or file path (at least in google case). The share can be updated from various places, by various clients. Thus it is better to use ID directly, because it is still the same. On the other hand, it brings various issues as mentioned. So I prefer to not expose IDs and handle the ID/path translation in backend internally (similarily what mtp backend does)...


Be aware of the following issue with google backend. Caching the whole drive metadata wasn't really the best idea:

Don't know what's the best solution, but I thought about downloading the metadata for each folder on demand and later probably modify the libzapojit to support the webhook interface if it's possible to track the changes in real time.

If I am not mistaken, the main reasons for caching the whole tree were google quotas and some issues with unreliable filtering by folder... See the proposed patch to make this per folder. If OneDrive hasn't similar issues, it is definitely better to always query only what is needed, without caching.

Also, other links on the following page may be useful for you:

2018-05-22 13:27 GMT+02:00 Adam Tauno Williams <awilliam whitemice org>:
> Thaks for pointing me to that feature request. I looked into the
> WebDAV redirection metioned there but it only works with
> username/password authentication it doesn't work with with the
> already available Oauth2 token stored in gnome-online-accounts. So
> users would have to log in separately and still there's virtualy no
> support for two phase authentication.

I have encountered some limitations with their WebDAV implementation -
so while good as a fallback it probably isn't a great solution.

> I wrote a program to test the also mentioned libzapojit library and
> as I can tell it works, I could authenticate through the
> ZpjGoaAuthorizer to get a list of files from my OneDrive. In my
> opinion it would be the best option to implement new gvfs backend
> same way Google Drive is. If this solution is alright I can start
> working on it.

Sounds awesome!

I will happily be a tester.  I poked around in the GVFS code way back
in the day.

--
Adam Tauno Williams <mailto:awilliam whitemice org> GPG D95ED383
OpenGroupware Developer <http://www.opengroupware.us/>




-- 
Vilém Hořínek <vilem horinek hotmail com>



--
Ondrej Holy
Software Engineer, Core Desktop Development
Red Hat Czech s.r.o


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]