Brammy wrote:The point I was trying to illustrate is that Dropbox is way more than just a sync service now with the Slack et al integration.
If that is your problem with Dropbox, have you looked at the huge list of bloated things that iCloud handles?
It sprawls as badly as iTunes.
iCloud is a complicated and over-engineered monster. I alluded to it above, but just because Apple hides this thing inside the operating system does not make it a slick, lightweight and cool. What that really means is that you have no choice in whether it is installed or not, and they can sprawl it deep into stuff that sync should have no business messing with in my opinion—and I state that as an ethical concern as well as a technical one. Just look at it this way: you have to give Dropbox permission to look at your photos. Did you give iCloud permission to do anything
? Apple doesn’t ask permission, they just upload your address book to the Internet like that’s cool to do, whereas in most cases we’d call that spyware.
But Dropbox integrates with a development toolkit, so it is clunky and bloated—abandon ship. Sure, sure.
Now the 3-device account limit on their freebie service, yeah I get the grumbles there (despite the whole Gift Horse Mouth bit), and like I say I get the preference
aspect, that is fine. But technical arguments for Dropbox being worse than iCloud just make my eyebrows rise.
Clearly, Apple is really good at selling stuff, while Dropbox does not care so much about that kind of thing. Now to a person like myself, that is actually not a point in Apple’s case; Bose is good at selling things too.
I don't think there is much to be gained by calling one system 'bloated' by comparing with another, when the two systems have different goals. iCloud is threaded throughout the operating system because Apple's customer base would probably get quite annoyed if they had keep track of syncing activities across multiple devices. Having it tied throughout the OS means that they can implement stuff like storage optimisation and have all apps code that meet their coding guidelines work without too much of a headache. Of secondary concern to Apple is how the design would look to folk of a more technical bent, because people who are concerned about such things are not really their core user base. What they care about is that it starts up and it works, without having to manually sync.
The problem to my mind, and the thing to pay attention to with this kind of technology, is not the affirmations of when it works correctly, but what happens when it does not. Because what happens when it fails is what we have to prepare for even when it seems to work fine for years. We post advisories about not using Google Drive even though the failure rates are a fraction of the people who use it (many of whom have used it for years). But because those fail states happen often enough, and because their condition is so catastrophic, we warn people away from the service entirely.
I'm not familiar with how Google drive works, but these cloud systems are no different than local hard disks; they will fail, so always make sure you have a backup, but that is a different issue. When they work, then your average user expects them to work without regular intervention. For me, iCloud works without me worrying about what's going on in the background, or how Apple has threaded iCloud throughout the operating system. It's not an everyday problem because, for the most part, it works everyday. It even works when I share the editing of a document with someone else.
A tiny change to a Scapple file (editing one note), resulted in a 45 minute wait for the file to sync. In the meantime if I had not realised that and assumed iCloud were as snappy as other services, I would have conflicted the file
Forty-five minutes is definitely excessive, but I'm not sure it's the norm, and if it's not the norm then I certainly wouldn't want Apple to implement manual syncing across the board to get around it. I would rather they found the problem and fixed it.
This is the same sort of thing you would have to do with iCloud if you messed up—but as I pointed out above, the experience is a whole lot more opaque and difficult to recover from.
How difficult depends on what you're doing. Apple's own apps will alert you to a conflict and ask you to review and select a file. Not sure what other apps do, because, as I said, I don't seem to see these problems.
The opaqueness of the file system is one of those design decisions you either agree or disagree with. Keeping the APIs as abstract as possible means they can do things like move millions of users to a new file system without any of them noticing.
For myself, this kind of catastrophic failure over a rather common misuse scenario is something I have a “One Strike You’re Out” policy on. When I saw iCloud destroy data, that was it. I had no interest in that system and I never will. I have never seen any other sync technology do anything like that, and every other sync tool I have tested has extensive safety nets built in, like archival folders, versioning and trash-buffer systems. Maybe iCloud is better now than it was when I tested it—but like I say, at this point I do not care and I never will, because any system published with the flaws I saw has said enough about itself.
That's fair enough, but I think we may be digressing. You had problems, and threw the whole thing out the window. I have never had a problem, and have backups for when I do, so all I see is a lot of apps that sync seamlessly, and one that doesn't.
You open Scrivener and it alerts you to the fact that Dropbox has created duplicate conflict files.
They are imported into the binder into one convenient location and cross-referenced to the items they are associated with if possible, making it easy to compare the two copies side by side.
Good example, but let's see it from another perspective:
You make sure that Scrivener is closed down on your Mac. You leave the house.
You open Scrivener on the bus, and wonder if you closed it down on your Mac. You put it out of your mind because you have the beginnings of a best seller you want to crack on with while you're on the bus.
You wait anything between 15 seconds and 2 minutes for Scrivener to get ready.
You crack on.
You get home before you even start Scrivener, Dropbox tells you you have 18 file conflicts.
You open Scrivener, and it says you have somewhat less.
You spend fifteen minutes comparing files which are all the same, except one where you changed 'their' to 'there'.
I understand your hatred of iCloud, and I will no doubt hate it too if I run into a problem, but I'm really just talking about a problem I'm seeing regularly, rather than one that hasn't happened and for which I'm sort of prepared for.
You're talking about the unreliability of iCloud.
I'm talking about the less than seamless workings of Scrivener syncing which I don't see in other apps, for whatever reason.
One thing worth noting is that rewriting Scrivener from the ground up is a euphemism for gutting pretty much all of the things that make it a unique tool for writers, with regards to large-scale research and text storage. We’re talking turning Scrivener into Yet Another Single File Text Editor, with all of the limitations that come with storing 200,000 words in a single file (and nothing much beyond those words, no research).
The other thing worth noting, and I see this misconception all over the place, is that unless Scrivener were gutted, then if we’re speaking of a hypothetical universe wherin Apple finally adds safe and simple support for bulk folder+file sync, using the iOS protocols—nothing would likely change about the procedure.
Well, I was simply quoting your chief programmer from earlier on in this thread
Yes, I realised a while back that moving to iCloud would not solve the problem, which kind of brings me back to my original message (before I got myself sidetracked), I don't think there is any point in blaming Apple or thinking they will change. I could be wrong but I suspect that they prefer that developers didn't delve into low-level data structures any more; they'd rather they stick to the standard APIs and guidelines so that their apps won't don't get orphaned when the make sweepingly inconvenient moves – like changing the packaging structure altogether.
And if it's fair to criticise Apple for burning iCloud into the OS, then it's also fair to criticise building an app in such a way as to tie a key operation, and possibly its future, to one particular vendor.
I personally don't make that criticism of Apple or L&L because I don't really know the full technical details of why those decisions were made, so I assume that they were made to serve the majority of the users.