Start a new topic

OneDrive support

Well, that is it, really: support for OneDrive as a storage backend would be awesome.


1 person likes this idea

I like the idea, that would be nice to have support for several storage backends.

I use Dropbox just for BeOrg sync, my usual cloud storage is Google Drive.

If people want to use this post as a place to put their vote in for OneDrive support that would be great. There are many different storage backends - each of which has an overhead for ongoing maintenance, so I want to make sure there are sufficient users before adding additional options.

Support for OneDrive for Business would be nice.

+1


I just found out about this app and am about to go and find my Dropbox details to use it. I live in OneDrive (personal and business accounts) nowadays.

+1 I work for the US govt and Dropbox is blocked but OneDrive isn't so I use only OneDrive.
+1
+1
Any chance this will be considered?

After adding Box sync and seeing very little uptake I've been a little more cautious about adding any other sync backends (as each requires testing for each release, SDKs need updating, etc). I want to add the ability for beorg to use any app which acts as a file provider if that turns out to be possible (may not for purposes of background refresh, etc so still some investigation to do). That way if One Drive supports being a file provider then beorg could use it. No ETA on this yet but I do hope to start looking into this soon.


1 person likes this
I would think OneDrive is more popular than Box but It's absolutely understandable that you need to put your effort where the best return is. I'll check if OneDrive is a file provider.

TLDR: Think Sync, not Storage.   =]


I think the main use case for most people adopting BeOrg is file syncing, particularly offline, not so much for simply storage as my hypothesis would be that most users are interested in a mobile clients for emacs org-mode than this as a stand alone iOS app. (so syncing, particularly offline availability would trump simple cloud storage).


I'd actually suggest taking a survey of users (if that's possible or even upvoting) to make sure you're developing the features which are goingto help you drive the community (and paid customers... you gotta eat). Flex those product management muscles. In particular if you can figure out between paid/tipping vs unpaid users that is interesting as well.


I know *personally*, I'd be keen to get sync.com support (in face, just filed a request) but that's because I want to move *off* Dropbox to it for both performance reasons (Dropbox agent seems to be going constantly berserk on OSX these days) and for enhanced security since they encrypt at rest (and also have a vault feature for my backups which right now I use a selective sync to avoid,.). YMMV.  =]


I also figure you're going to see a much higher proportion of "roll your own" people paying than not. For example, a lot of emacs users will be comfy using OwnCloud etc rather than paid commerical services like Box or Goog or OneDrive though they may have access them. I have a large goog drive, I pay for dropbox for example because I need stuff offline syncing and wish to symlink folders so I have a common experience across linux and osx desktops.  =]


ciao!

Daryl.

The thing is, that my company does not allow any cloud solution different than OneDrive for Business or Adobe Creative Cloud. Even iCloud is not permitted.

Privately I'm using iCloud and this works very well for me.

I'd be curious for Matthew whether there is a more generalized interface available to most of the cloud providers he could use as a drop in for the code base (much like the fog library in ruby land or similar in other langs. I'm not a Swift or ObjC guy so can't say. Tho will check around in React Native.).


I agree with him though, without a generalized interface it is probably something he'd need people to agree to pay for and pony up to see (ahead of him building it. Almost like a kickstarter.  =] ). It's not fair otherwise and a bit like guessing as to uptake. =]

 

Support for plugins containing compiled executable code just isn't allowed by Apple at the moment - and I can't imagine it will be at any point in the near future unfortunately.


Having said that however I wonder whether it would be possible for beorg to offer a way to use JavaScript for providing access to sync. For each sync service the following needs to be implemented:


+ Authorisation

+ Checking whether authorised

+ Getting a list of Org files (with last modified dates, and optionally version if supported by sync service)

+ Downloading a file which has changed remotely

+ Uploading a file changed in beorg

+ Deleting a file


1 person likes this
Login or Signup to post a comment