Jump to content
pruppert

First party sync service

Recommended Posts

I’d like to stop using Dropbox since iCloud has replaced its function for me, but Alfred sync is on of the few things holding me back. I see it is not recommended to use iCloud Drive. Perhaps a new version of Alfred could have sync built in without any need for a third party like Dropbox or iCloud Drive? Thanks.

Share this post


Link to post
Share on other sites
10 hours ago, dfay said:

Why not just keep using Dropbox at the free level? 

 

It’s an extra app and service you have to worry about on your system. And it’s one that can at times be really resource intensive and has privacy implications (I remember something about them possibly scanning all your hard drive).

 

12 hours ago, pruppert said:

Perhaps a new version of Alfred could have sync built in

 

That seems unlikely, and I doubt you (or anyone else) would actually want that. It’d not only increase the cost of Alfred as an app, it would likely need to move to a subscription service. Alfred Preferences, since they include Workflows, can easily go for over 100MB (don’t even want to image for people who install Node Workflows). That amount of storage for each user, plus the overhead of coding and maintaining the sync server and maintaining said server would quickly shift Alfred’s focus. And how would you prevent abuse (people storing too much)? Now you either have people unhappy because they can’t sync everything, or you need to introduce paid tiers. The whole thing would quickly devolve into a mess not worth it for a two-person (one coder) team, seeing as the vast majority of users are happy with things the way they are.

 

12 hours ago, pruppert said:

I see it is not recommended to use iCloud Drive.

 

It’s not recommended because iCloud Drive has been unreliable for people in the past, going so far as to make them lose their preferences. But you aren’t forbidden from using it; you just need to be wary that if something goes wrong, you have been warned. If you’re using iCloud Drive as your primary source for everything else, you should be fine. Just remember to turn off the feature that deletes unused files from your machine (System Preferences → iCloud → iCloud Drive (Options…) → [unckeck] Optimize Mac Storage).

Share this post


Link to post
Share on other sites

@vitor, you have correctly summarized my reasons for wanting to move away from Dropbox. Your points on first party sync are also well made.

 

So is it your understanding that the iCloud issues were exclusively related to the Optimize Mac Storage settings? If that's the case, I'll probably go with iCloud since I have that setting disabled anyway.

Share this post


Link to post
Share on other sites
5 minutes ago, pruppert said:

So is it your understanding that the iCloud issues were exclusively related to the Optimize Mac Storage settings?

 

Likely not exclusively. iCloud Drive was notoriously unreliable when it debuted. That said, I haven’t heard of any major issues for a good while. If that’s because it has improved or because most people stopped using it, I can’t say. Probably a bit of both.

 

In your shoes, I’d go for it but remember to backup everything once in a while.

 

That said, I do use iCloud Drive a lot with iA Writer, and haven’t had any trouble I recall (or that I noticed!).

Share this post


Link to post
Share on other sites

Dropbox are now limiting "free" access to three devices - they haven't communicated this change to users at all!

 

If you are an existing user with more than three devices then you can continue, but you won't be able to add new devices including when you change devices (if that would take you over the limit).

 

https://help.dropbox.com/account/computer-limit

 

Dave

Share this post


Link to post
Share on other sites
On 2/1/2019 at 4:16 AM, pruppert said:

Providing an update that I've been running my Alfred prefs in iCloud Drive for the past month without any issues.

Do you turn off the Optimized Storage option?

Share this post


Link to post
Share on other sites
Posted (edited)
On 12/14/2018 at 10:46 PM, vitor said:

That seems unlikely, and I doubt you (or anyone else) would actually want that. It’d not only increase the cost of Alfred as an app, it would likely need to move to a subscription service. Alfred Preferences, since they include Workflows, can easily go for over 100MB (don’t even want to image for people who install Node Workflows). That amount of storage for each user, plus the overhead of coding and maintaining the sync server and maintaining said server would quickly shift Alfred’s focus. And how would you prevent abuse (people storing too much)? Now you either have people unhappy because they can’t sync everything, or you need to introduce paid tiers. The whole thing would quickly devolve into a mess not worth it for a two-person (one coder) team, seeing as the vast majority of users are happy with things the way they are.

Why this will increase the cost? Tons of app using Apple CloudKit to sync between devices. No need to maintain the sync server. The storage count towards user's iCloud drive storage, so there is no abuse issue either.

Edited by sdd11

Share this post


Link to post
Share on other sites
1 hour ago, sdd11 said:

Tons of app using Apple CloudKit to sync between devices. No need to maintain the sync server. The storage count towards user's iCloud drive storage, so there is no abuse issue either.

 

Then it’s no longer a “first-party sync service”, which is the topic we’re discussing. There’s no point to building CloudKit integration; if you want to sync with iCloud (and have it count towards your iCloud data storage limit), then set your sync directory there. Alfred already supports what you’re suggesting, it just advises against it due to problems with the service in the past.

Share this post


Link to post
Share on other sites
13 hours ago, vitor said:

There’s no point to building CloudKit integration; if you want to sync with iCloud (and have it count towards your iCloud data storage limit), then set your sync directory there. Alfred already supports what you’re suggesting, it just advises against it due to problems with the service in the past.

Many apps using CloudKit work totally fine for me. I guess the reason why syncing file using iCloud is unreliable is that iCloud does not understand directory and file structure very well thus can not resolve conflict. By using CloudKit, developer can specify file infomation such as revision which can avoid conflict. Using CloudKit is much more user friendly. User does not need to set it up manually.

Share this post


Link to post
Share on other sites
Posted (edited)
1 hour ago, sdd11 said:

Using CloudKit is much more user friendly. User does not need to set it up manually.

 

You’d still need to specify if you wanted to use CloudKit at all in this case, so you’d still need manual setup. Exact same number os steps.

Edited by vitor

Share this post


Link to post
Share on other sites
9 hours ago, sdd11 said:

developer can specify file infomation such as revision which can avoid conflict

 

CloudKit may work just fine for applications that manage their own data using its APIs, but that isn't Alfred.

 

A lot of the files being synced don't belong to Alfred: they belong to workflows. As a result, Alfred isn't in a position to manage (via revisions or whatever) the many sync conflicts iCloud's crapness causes because Alfred doesn't have sufficient information to do so.

 

Alfred's current sync Just Works with any software that can reliably sync files/directories, be it Dropbox, rsync, Unison, Seafile or whatever.

 

You're talking about completely rewriting Alfred's sync/file management in order to use a service that has a long history of losing data. Replacing a system that works wonderfully (if you're using reliable sync software).

 

The new limitations to Dropbox's free accounts suck, but I'm not convinced that's a sound reason to ditch a working, platform-agnostic sync solution for one that's tied to a legendarily unreliable service.

Share this post


Link to post
Share on other sites
14 hours ago, deanishe said:

 

CloudKit may work just fine for applications that manage their own data using its APIs, but that isn't Alfred.

 

A lot of the files being synced don't belong to Alfred: they belong to workflows. As a result, Alfred isn't in a position to manage (via revisions or whatever) the many sync conflicts iCloud's crapness causes because Alfred doesn't have sufficient information to do so.

 

Alfred's current sync Just Works with any software that can reliably sync files/directories, be it Dropbox, rsync, Unison, Seafile or whatever.

 

You're talking about completely rewriting Alfred's sync/file management in order to use a service that has a long history of losing data. Replacing a system that works wonderfully (if you're using reliable sync software).

 

The new limitations to Dropbox's free accounts suck, but I'm not convinced that's a sound reason to ditch a working, platform-agnostic sync solution for one that's tied to a legendarily unreliable service.

Make sense. Then I will use reliable sync software.

Share this post


Link to post
Share on other sites

FWIW, Seafile has worked well for me in the past. I don’t use it any more, though, because Dropbox handles symlinks better.

 

You need a server for Seafile, however. Syncthing is pure peer-to-peer and works very well. But without a server, the machines will only sync when both are online.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...