Jump to content

sdd11

Member
  • Posts

    4
  • Joined

  • Last visited

Posts posted by sdd11

  1. 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.

  2. 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.

  3. 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.

×
×
  • Create New...