Discussion:
A few ICloud Questions
(too old to reply)
Skylamar
2011-11-07 07:00:40 UTC
Permalink
Hi. I just activated my ICloud account and I have a few questions.

I don't own an iOS device. I just own a Mac. I also own Pages, but the
'08 version. So, assuming I buy the latest version of Pages, I'm
wondering the following:

- Can ICloud display iWork documents on its website?

- Is there a way to limit which iWork documents my Mac syncs with
iCloud? For instance, I'm looking for employment and I'm sending out a
bunch of different cover letters, written in Pages, every day and I
wouldn't want all of them synced with iCloud.

Thanks,

Sky
Michelle Steiner
2011-11-07 16:24:27 UTC
Permalink
Post by Skylamar
I don't own an iOS device. I just own a Mac. I also own Pages, but the
'08 version. So, assuming I buy the latest version of Pages, I'm
- Can ICloud display iWork documents on its website?
It can display that the document is there, but not the contents of the
document. But so far as I know, there's no public folder in iCloud as
there is in Mobile Me. So you can't use iCloud to distribute documents to
other people.
Post by Skylamar
- Is there a way to limit which iWork documents my Mac syncs with
iCloud? For instance, I'm looking for employment and I'm sending out a
bunch of different cover letters, written in Pages, every day and I
wouldn't want all of them synced with iCloud.
You have to manually upload documents to iCloud from the Mac; it does not
automatically sync documents like the iOS devices do.
--
Tea Party Patriots is to Patriotism as
People's Democratic Republic is to Democracy.
B***@fractious.net
2011-11-07 19:23:26 UTC
Permalink
Post by Michelle Steiner
You have to manually upload documents to iCloud from the Mac; it does not
automatically sync documents like the iOS devices do.
There are some great alternatives which do automatically sync
parts of your filesystem between computers (and including access
via iOS devices). iCloud clearly isn't the answer, but
DropBox, Wuala, SugarSync and a few others may fit the bill.
--
Plain Bread alone for e-mail, thanks. The rest gets trashed.
Lloyd E Parsons
2011-11-07 19:45:25 UTC
Permalink
Post by B***@fractious.net
Post by Michelle Steiner
You have to manually upload documents to iCloud from the Mac; it does not
automatically sync documents like the iOS devices do.
There are some great alternatives which do automatically sync
parts of your filesystem between computers (and including access
via iOS devices). iCloud clearly isn't the answer, but
DropBox, Wuala, SugarSync and a few others may fit the bill.
One most mac users don't think of that works quite well is Microsoft
Live Mesh drive. It gives 5Gb of space, works cross platform and costs
nothing.

I have my shareable docs folder and my keychain folders all syncing at
the Mesh drive location, and also syncing with my Windows and Macs boxes.
--
Lloyd
B***@fractious.net
2011-11-08 17:41:09 UTC
Permalink
Post by Lloyd E Parsons
Post by B***@fractious.net
DropBox, Wuala, SugarSync and a few others may fit the bill.
One most mac users don't think of that works quite well is Microsoft
Live Mesh drive. It gives 5Gb of space, works cross platform and
costs nothing.
Nice to know about, thanks.

I use Wuala and DropBox. Since Box.net is giving away 50GB
of storage for life for anyone who signs up using an iOS
client, I signed up for that, too, but if you want sync,
you have to buy into one of their business accounts @ $15/mo.
(Which, admittedly, includes a lot of other stuff, too, but
it's overkill for my needs right now).
--
Plain Bread alone for e-mail, thanks. The rest gets trashed.
Michelle Steiner
2011-11-07 21:42:03 UTC
Permalink
Post by Michelle Steiner
You have to manually upload documents to iCloud from the Mac; it does
not automatically sync documents like the iOS devices do.
There are some great alternatives which do automatically sync parts of
your filesystem between computers (and including access via iOS
devices). iCloud clearly isn't the answer,
Not yet, anyway.
--
Tea Party Patriots is to Patriotism as
People's Democratic Republic is to Democracy.
Tom Harrington
2011-11-08 03:55:33 UTC
Permalink
Post by B***@fractious.net
Post by Michelle Steiner
You have to manually upload documents to iCloud from the Mac; it does not
automatically sync documents like the iOS devices do.
There are some great alternatives which do automatically sync
parts of your filesystem between computers (and including access
via iOS devices). iCloud clearly isn't the answer, but
DropBox, Wuala, SugarSync and a few others may fit the bill.
iCloud is the answer to a different question than those services.
--
Tom "Tom" Harrington
Independent Mac OS X developer since 2002
http://www.atomicbird.com/
B***@fractious.net
2011-11-08 04:25:12 UTC
Permalink
Post by Tom Harrington
Post by B***@fractious.net
Post by Michelle Steiner
You have to manually upload documents to iCloud from the Mac; it does not
There are some great alternatives which do automatically sync
parts of your filesystem between computers (and including access
via iOS devices). iCloud clearly isn't the answer, but
DropBox, Wuala, SugarSync and a few others may fit the bill.
iCloud is the answer to a different question than those services.
iCloud is apparently *supposed* to be the answer to the question
of getting your documents into the 'cloud' (as well as the things
it actually does well like your addressbook and calendars).

If you have to manually upload your documents to it (as Michelle
is quoted above saying), then iCloud fails as the answer to
that part of the question.

One of the problems is that it just isn't clear what iCloud is
or is supposed to be doing for us. The addressbook and calendar
syncing is nothing new. Photostream may be a good thing, but
I really haven't much interest in it - I'm quite happy with my
MobileMe galleries (which are going to go away). So what's left?

In my opinion, Apple has failed to really wow us with anything
really groundbreaking in iCloud, at least as of yet. Maybe
photostream and music match will really make it stand out, but
it's not clear.

Meanwhile, other third party companies have come in and done
what Apple hasn't -- made it easy to keep your documents in
the cloud in a way that they are immediately and easily useful
on multiple machines and platforms without having to do anything
extra like uploading them via web page. Apple has basically
managed to make addressbook and calendars work about that well,
but never general documents.

Jobs tried to buy DropBox out - he saw how good it was, even though
he called it a "feature" not an app. Maybe it is just a feature,
but nobody else seems to have managed to make anything else work as
easily and transparently, nor gotten loads of third-party apps to
use it so well. There are others that work just about as easily
but have different features (ie. SugarSync and Wuala, both of
which have a lot of overlap with DropBox).

I really hope Apple improves iCloud and, maybe, clarifies its
mission a little better. And it'd be nice for Apple to support
Snow Leopard with it - they are supporting two generations of
Windows but not MacOS? But meanwhile, it doesn't seem very
compelling.
--
Plain Bread alone for e-mail, thanks. The rest gets trashed.
Michelle Steiner
2011-11-08 06:43:16 UTC
Permalink
If you have to manually upload your documents to it (as Michelle is
quoted above saying), then iCloud fails as the answer to that part of
the question.
Only from the Mac; it's automatic with iOS. I'm sure that the next major
revision of iWork will allow automatic uploads from the Mac; I'd be very
surprised if it didn't.

-- Michelle
--
Tea Party Patriots is to Patriotism as
People's Democratic Republic is to Democracy.
B***@fractious.net
2011-11-08 17:22:28 UTC
Permalink
Post by Michelle Steiner
If you have to manually upload your documents to it (as Michelle is
quoted above saying), then iCloud fails as the answer to that part of
the question.
Only from the Mac; it's automatic with iOS. I'm sure that the next major
revision of iWork will allow automatic uploads from the Mac; I'd be very
surprised if it didn't.
That's still nowhere near enough - it needs to be general-purpose,
not just iWork documents, though that'd be a start.

Seriously, Apple's just way behind on this. And Jobs knew it -
he offered the DropBox guys $800million for the company:

http://www.businessinsider.com/heres-the-gossip-on-apples-800-million-offer-for-one-sexy-silicon-valley-startup-dropbox-2011-9
--
Plain Bread alone for e-mail, thanks. The rest gets trashed.
Michelle Steiner
2011-11-09 06:14:36 UTC
Permalink
Post by Michelle Steiner
If you have to manually upload your documents to it (as Michelle is
quoted above saying), then iCloud fails as the answer to that part of
the question.
Only from the Mac; it's automatic with iOS. I'm sure that the next
major revision of iWork will allow automatic uploads from the Mac; I'd
be very surprised if it didn't.
That's still nowhere near enough - it needs to be general-purpose, not
just iWork documents, though that'd be a start.
Each app has to become iCloud aware and use the iCloud APIs.
Seriously, Apple's just way behind on this. And Jobs knew it -
Apps have to be DropBox aware too, right?
--
Tea Party Patriots is to Patriotism as
People's Democratic Republic is to Democracy.
Barry Margolin
2011-11-09 07:37:19 UTC
Permalink
Post by Michelle Steiner
Post by Michelle Steiner
If you have to manually upload your documents to it (as Michelle is
quoted above saying), then iCloud fails as the answer to that part of
the question.
Only from the Mac; it's automatic with iOS. I'm sure that the next
major revision of iWork will allow automatic uploads from the Mac; I'd
be very surprised if it didn't.
That's still nowhere near enough - it needs to be general-purpose, not
just iWork documents, though that'd be a start.
Each app has to become iCloud aware and use the iCloud APIs.
Seriously, Apple's just way behind on this. And Jobs knew it -
Apps have to be DropBox aware too, right?
Perhaps what he's suggesting is that iCloud should provide an interface
like iDisk, where the cloud appears as a volume on your desktop. And you
could choose to have folders like Documents, Music, etc. be located on
this volume.

If something like this were done, applications wouldn't need to be aware
of it at all. It would look to them just like any other disk, and the
OS would take care of syncing for them.
--
Barry Margolin, ***@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
B***@fractious.net
2011-11-09 07:37:48 UTC
Permalink
Post by Michelle Steiner
That's still nowhere near enough - it needs to be general-purpose, not
just iWork documents, though that'd be a start.
Each app has to become iCloud aware and use the iCloud APIs.
Ugh. Remember - we are talking about Macs here, not iOS
devices. On iOS apps don't have a common filesystem. On
the Mac, there's no reason not to take advantage of it.
Post by Michelle Steiner
Seriously, Apple's just way behind on this. And Jobs knew it -
Apps have to be DropBox aware too, right?
Not at all. On the desktop, any cloud system which either
uses sync or which attaches as a regular old filesystem
may be written to by any application.

Anything I'm actively working on lives either in a directory
which gets synced via Dropbox or Wuala right now.

Perhaps I misread the whole iCloud thing, but my impression
was that it should ultimately allow something similar. At
this point, it looks to me like it'll be useful only for
address book and calendaring. Nice but no wow.
--
Plain Bread alone for e-mail, thanks. The rest gets trashed.
Michelle Steiner
2011-11-09 14:53:22 UTC
Permalink
Post by Michelle Steiner
Post by B***@fractious.net
That's still nowhere near enough - it needs to be general-purpose,
not just iWork documents, though that'd be a start.
Each app has to become iCloud aware and use the iCloud APIs.
Ugh. Remember - we are talking about Macs here, not iOS devices. On
iOS apps don't have a common filesystem. On the Mac, there's no reason
not to take advantage of it.
Right, but that merely agrees with what I wrote: The app itself has to be
iCloud aware.
Post by Michelle Steiner
Post by B***@fractious.net
Seriously, Apple's just way behind on this. And Jobs knew it - he
Apps have to be DropBox aware too, right?
Not at all. On the desktop, any cloud system which either uses sync or
which attaches as a regular old filesystem may be written to by any
application.
I don't understand what you're saying here.

-- Michelle
--
Tea Party Patriots is to Patriotism as
People's Democratic Republic is to Democracy.
B***@fractious.net
2011-11-09 16:02:57 UTC
Permalink
Post by Michelle Steiner
Post by Michelle Steiner
Post by B***@fractious.net
That's still nowhere near enough - it needs to be general-purpose,
not just iWork documents, though that'd be a start.
Each app has to become iCloud aware and use the iCloud APIs.
Ugh. Remember - we are talking about Macs here, not iOS devices. On
iOS apps don't have a common filesystem. On the Mac, there's no reason
not to take advantage of it.
Right, but that merely agrees with what I wrote: The app itself has to be
iCloud aware.
Um, no. There's no reason applications should know or care
that they are dealing with iCloud rather than a local filesystem.

Given that applications on the desktop are generally already fully
capable of using the the local filesystem, why add another
element to the interface for no good reason?
Post by Michelle Steiner
Post by Michelle Steiner
Post by B***@fractious.net
Seriously, Apple's just way behind on this. And Jobs knew it - he
Apps have to be DropBox aware too, right?
Not at all. On the desktop, any cloud system which either uses sync or
which attaches as a regular old filesystem may be written to by any
application.
I don't understand what you're saying here.
I use DropBox and Wuala right now. I work in Excel, Numbers, Pages,
whatever. I save my files in the filesystem just like I always
have before the cloud. My files are just magically there -
accessible from all of my computers - macs, windows, iPads -
without me having to do anything extra or special. Documents
are simply there.

Nobody had to tell the applications to know about the cloud.
And I don't have to think about it, either. My documents
folder and all the subfolders, particularly project folders
which contain multiple filetypes in a single folder, are all
just there.

AddressBook and Calendar, mostly, work the same way - but
because they don't generally have the user think about or
use files (explicitly - they save data in their own place),
they could have been modified to use something like Wuala or
DropBox by simply allowing the user to choose where the
data files get stored. (This is actually what 1Password
does, in fact. You just keep your repository in ~/Dropbox
rather than somewhere in ~/Library) Instead, they hide the
data files from the user and use their own interface to sync
services. In this case, it's probably better that way (though
it's actually had a few issues for me over the years. In the
much earlier days of mobileme syncing, AddressBook twice
completely hosed my content during syncing and I learned to
regularly export separate backups).
--
Plain Bread alone for e-mail, thanks. The rest gets trashed.
Michelle Steiner
2011-11-09 16:29:38 UTC
Permalink
Post by B***@fractious.net
Post by Michelle Steiner
Right, but that merely agrees with what I wrote: The app itself has to be
iCloud aware.
Um, no. There's no reason applications should know or care
that they are dealing with iCloud rather than a local filesystem.
Um, because that's the way iCloud is designed? I'm writing about how it
is; you're writing about how you think it should be.
Post by B***@fractious.net
Post by Michelle Steiner
I don't understand what you're saying here.
I use DropBox and Wuala right now. I work in Excel, Numbers, Pages,
whatever. I save my files in the filesystem just like I always have
before the cloud. My files are just magically there - accessible from
all of my computers - macs, windows, iPads - without me having to do
anything extra or special. Documents are simply there.
Nobody had to tell the applications to know about the cloud. And I don't
have to think about it, either. My documents folder and all the
subfolders, particularly project folders which contain multiple
filetypes in a single folder, are all just there.
But you have to designate which folders DropBox and Wuala look at, and have
to save the files to those folders, right? As I understand it, with
iCloud, you don't have to set up anything; you can save the document
anywhere you want, and it's uploaded to the cloud automatically. For
iCloud aware apps, that is.

Anyway, it's too early to tell how iCloud will develop. My interest is
academic and minimal, so I'm going to bow out of the discussion.
--
Tea Party Patriots is to Patriotism as
People's Democratic Republic is to Democracy.
B***@fractious.net
2011-11-09 16:49:31 UTC
Permalink
Post by Michelle Steiner
Um, because that's the way iCloud is designed? I'm writing about how it
is; you're writing about how you think it should be.
That's the thing - even though it's already out, it's not
clear how it's designed or what it's doing for us. It's
just weird. Landed with a thud. As it is - as shipped -
you yourself explained about using a web page to upload
and download files. Seriously?
Post by Michelle Steiner
But you have to designate which folders DropBox and Wuala look at, and have
to save the files to those folders, right? As I understand it, with
There are defaults, but you have a lot of flexibility. For example,
I move my ~/Documents folder into Dropbox and put an alias at
~/Documents to point to it. It's possible to just have Dropbox
sync up your ~/Documents itself rather than ~/Dropbox. The point
is that you have all the flexibility of the existing filesystem
to work with. If anyone's come up with anything better than
that, I've yet to see it.
Post by Michelle Steiner
iCloud, you don't have to set up anything; you can save the document
anywhere you want, and it's uploaded to the cloud automatically. For
iCloud aware apps, that is.
That'd be fascinating. Weird and as-yet-unheard-of - with some
questions I'd have immediately. But if that's how it's going to
be, it'd be nice if Apple would say something. All I've got to
go off of is how Apple has already done it.
Post by Michelle Steiner
Anyway, it's too early to tell how iCloud will develop. My interest is
academic and minimal, so I'm going to bow out of the discussion.
No problem. I'm just baffled about Apple's iCloud strategy.
Either it's going to be amazing and they've completely fallen
down in telling us just how. Or it's going to be another
iteration of .mac and MobileMe and Steve's ghost is not going
to be very happy about it. Long as I can keep doing what's
been working for me (using MobileMe or equiv for the things
it actually does well and using the excellent alternatives
for the things that don't), I'll be happy.

But they've either failed with the product, failed with the
rollout plans or failed with the marketing and education and
that's very unlike how Apple does most other things.
--
Plain Bread alone for e-mail, thanks. The rest gets trashed.
Michelle Steiner
2011-11-09 17:53:27 UTC
Permalink
As it is - as shipped - you yourself explained about using a web page to
upload and download files. Seriously?
This is usenet; it's hard to bow out of a discussion. <g>

Yes, that's how it is right now. The current version of iWork apps on the
Mac was written before iCloud, so they're not iCloud aware. The web-page
method is, I believe, a temporary measure until iCloud-aware versions of
the iWork apps can be released. Then it will become transparent. I trust
that there will be an option so the user can decide whether apps will go on
the cloud or not, as is done with the iOS versions of those apps.

In each iOS iWork app's preferences, there's a "Use iCloud" toggle. If
it's toggled on, when you close a document, it's automatically put on the
cloud. When you open the app, you see a list of saved documents, and
they're all on the Cloud as well, and accessible from any device that can
access your iCloud account.
Post by Michelle Steiner
iCloud, you don't have to set up anything; you can save the document
anywhere you want, and it's uploaded to the cloud automatically. For
iCloud aware apps, that is.
That'd be fascinating. Weird and as-yet-unheard-of - with some
questions I'd have immediately. But if that's how it's going to be,
it'd be nice if Apple would say something. All I've got to go off of is
how Apple has already done it.
You know how Apple is with unannounced products; they won't even
acknowledge that those products are being developed, let alone say what
their features are.
--
Tea Party Patriots is to Patriotism as
People's Democratic Republic is to Democracy.
Paul Sture
2011-11-13 00:23:44 UTC
Permalink
There are defaults, but you have a lot of flexibility. For example, I
move my ~/Documents folder into Dropbox and put an alias at ~/Documents
to point to it. It's possible to just have Dropbox sync up your
~/Documents itself rather than ~/Dropbox. The point is that you have
all the flexibility of the existing filesystem to work with. If
anyone's come up with anything better than that, I've yet to see it.
This chap is using Dropbox for the web documents directory in a test
environment:

<http://nerdbusiness.com/blog/sync-your-drupal-sites-xampp-and-dropbox>

Note the link at the end where he addresses replicating a MySQL database.
--
Paul Sture

"The trouble with quotes on the internet is that it's difficult to
determine whether or not they are genuine." -- Abraham Lincoln
Bob Harris
2011-11-10 02:56:03 UTC
Permalink
Post by B***@fractious.net
Post by Michelle Steiner
Post by Michelle Steiner
Post by B***@fractious.net
That's still nowhere near enough - it needs to be general-purpose,
not just iWork documents, though that'd be a start.
Each app has to become iCloud aware and use the iCloud APIs.
Ugh. Remember - we are talking about Macs here, not iOS devices. On
iOS apps don't have a common filesystem. On the Mac, there's no reason
not to take advantage of it.
Right, but that merely agrees with what I wrote: The app itself has to be
iCloud aware.
Um, no. There's no reason applications should know or care
that they are dealing with iCloud rather than a local filesystem.
Given that applications on the desktop are generally already fully
capable of using the the local filesystem, why add another
element to the interface for no good reason?
Post by Michelle Steiner
Post by Michelle Steiner
Post by B***@fractious.net
Seriously, Apple's just way behind on this. And Jobs knew it - he
Apps have to be DropBox aware too, right?
Not at all. On the desktop, any cloud system which either uses sync or
which attaches as a regular old filesystem may be written to by any
application.
I don't understand what you're saying here.
I use DropBox and Wuala right now. I work in Excel, Numbers, Pages,
whatever. I save my files in the filesystem just like I always
have before the cloud. My files are just magically there -
accessible from all of my computers - macs, windows, iPads -
without me having to do anything extra or special. Documents
are simply there.
Nobody had to tell the applications to know about the cloud.
And I don't have to think about it, either. My documents
folder and all the subfolders, particularly project folders
which contain multiple filetypes in a single folder, are all
just there.
AddressBook and Calendar, mostly, work the same way - but
because they don't generally have the user think about or
use files (explicitly - they save data in their own place),
they could have been modified to use something like Wuala or
DropBox by simply allowing the user to choose where the
data files get stored. (This is actually what 1Password
does, in fact. You just keep your repository in ~/Dropbox
rather than somewhere in ~/Library) Instead, they hide the
data files from the user and use their own interface to sync
services. In this case, it's probably better that way (though
it's actually had a few issues for me over the years. In the
much earlier days of mobileme syncing, AddressBook twice
completely hosed my content during syncing and I learned to
regularly export separate backups).
The only problem with a Dropbox approach is that it is limited to
entire file copies. If you have "Record" oriented data, where
data could be updated in multiple places between syncs, then an
entire file update will result in the most recent system to update
winning, and all other systems loosing their changes.

Think of shared calendars, contacts, etc... While updates might
not be to the same entries, it is important to only update the
changed records, and not the entire file.
Wes Groleau
2011-11-10 05:26:11 UTC
Permalink
Post by Bob Harris
The only problem with a Dropbox approach is that it is limited to
entire file copies. If you have "Record" oriented data, where
data could be updated in multiple places between syncs, then an
entire file update will result in the most recent system to update
winning, and all other systems loosing their changes.
Not with DropBox. When you edit the file, the server is updated almost
immediately. When you log in to the other system, you get that update
immediately. IF for some perverse reason, you update this_file on Mac1
and Mac2 at the exact same time, the server will contain:

this_file(Mac2 conflicted copy)
this_file(Mac1 conflicted copy)

Furthermore, nothing prevents DropBox from using something like rsync to
do the updates, in which the sync is speeded up by only sending the
bytes that are changed.
--
Wes Groleau

“Statistics are like bikinis.
What they reveal is suggestive,
but what they conceal is vital.”
— Aaron Levenstein
Barry Margolin
2011-11-10 12:58:28 UTC
Permalink
Post by Wes Groleau
Post by Bob Harris
The only problem with a Dropbox approach is that it is limited to
entire file copies. If you have "Record" oriented data, where
data could be updated in multiple places between syncs, then an
entire file update will result in the most recent system to update
winning, and all other systems loosing their changes.
Not with DropBox. When you edit the file, the server is updated almost
immediately.
Even if you're not connected to the Internet at the time? Amazing!
Post by Wes Groleau
When you log in to the other system, you get that update
immediately. IF for some perverse reason, you update this_file on Mac1
this_file(Mac2 conflicted copy)
this_file(Mac1 conflicted copy)
Furthermore, nothing prevents DropBox from using something like rsync to
do the updates, in which the sync is speeded up by only sending the
bytes that are changed.
His point is that cloud-aware applications can deal better with data
where individual records, rather than whole files, are the chunks that
matter.

But there's no reason you can't have both. Most applications just deal
with documents, and they can use the normal filesystem API, and the
cloud filesystem will sync them transparently. Applications that want
finer-grained control can make use of a cloud API.
--
Barry Margolin, ***@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Wes Groleau
2011-11-11 06:47:21 UTC
Permalink
Post by Barry Margolin
His point is that cloud-aware applications can deal better with data
where individual records, rather than whole files, are the chunks that
matter.
That's not what he said. He said that with DropBox, if two systems
change different parts of the same file, one of the changes will be
lost. I described why that is not true.

"Better" is a matter of definition. There are certainly more
efficient methods than that used by DropBox. But most of the
time, the end result is the same, and none of the time is any
data lost.
--
Wes Groleau

If you put garbage in a computer nothing comes out but garbage.
But this garbage, having passed through a very expensive machine,
is somehow ennobled and none dare criticize it.
Tom Stiller
2011-11-10 14:54:11 UTC
Permalink
Post by Wes Groleau
Post by Bob Harris
The only problem with a Dropbox approach is that it is limited to
entire file copies. If you have "Record" oriented data, where
data could be updated in multiple places between syncs, then an
entire file update will result in the most recent system to update
winning, and all other systems loosing their changes.
Not with DropBox. When you edit the file, the server is updated almost
immediately. When you log in to the other system, you get that update
immediately. IF for some perverse reason, you update this_file on Mac1
this_file(Mac2 conflicted copy)
this_file(Mac1 conflicted copy)
Which does nothing to help resolve the conflict.
The problem is easy to trigger when the file being shared is a
sparsebundle which was opened on Mac2 before all the bands updated by
Mac1 were fully downloaded, as in the file sparsebundle was opened as a
part of login or very soon after.
Post by Wes Groleau
Furthermore, nothing prevents DropBox from using something like rsync to
do the updates, in which the sync is speeded up by only sending the
bytes that are changed.
Are you saying that is what happens?
--
PRAY, v. To ask that the laws of the universe be annulled in behalf
of a single petitioner confessedly unworthy. -- Ambrose Bierce
Wes Groleau
2011-11-11 06:51:20 UTC
Permalink
Post by Tom Stiller
Post by Wes Groleau
[snip] If you have "Record" oriented data, where
data could be updated in multiple places between syncs, then an
entire file update will result in the most recent system to update
winning, and all other systems loosing their changes.
Not with DropBox. When you edit the file, the server is updated almost
immediately. When you log in to the other system, you get that update
immediately. IF for some perverse reason, you update this_file on Mac1
this_file(Mac2 conflicted copy)
this_file(Mac1 conflicted copy)
Which does nothing to help resolve the conflict.
He didn't say either system would resolve a conflict.
He said (incorrectly) that DropBox would lose data.
Post by Tom Stiller
Post by Wes Groleau
Furthermore, nothing prevents DropBox from using something like rsync to
do the updates, in which the sync is speeded up by only sending the
bytes that are changed.
Are you saying that is what happens?
No. I am saying nothing is preventing DropBox from using
something more efficient than entire file transfer.
"More efficient" would reduce the already small chance
of a conflict.
--
Wes Groleau

“But, Professor! I didn't plagiarize! I paid someone to
write the essay for me, and that person plagiarized!"
— from http://rateyourstudents.blogspot.com
Michelle Steiner
2011-11-10 15:35:50 UTC
Permalink
Post by Wes Groleau
Not with DropBox. When you edit the file, the server is updated almost
immediately.
When you edit it, or when you save it?
Post by Wes Groleau
Furthermore, nothing prevents DropBox from using something like rsync to
do the updates, in which the sync is speeded up by only sending the
bytes that are changed.
What happens when two people change the same bytes, but make different
changes?

Many database systems handle this kind of conflict by locking out any
records that are being edited. If I'm editing a record, no one else can
edit it until I finish my work on it.
--
Tea Party Patriots is to Patriotism as
People's Democratic Republic is to Democracy.
Wes Groleau
2011-11-11 06:55:53 UTC
Permalink
Post by Michelle Steiner
Post by Wes Groleau
Not with DropBox. When you edit the file, the server is updated almost
immediately.
When you edit it, or when you save it?
When you save it.
Post by Michelle Steiner
Post by Wes Groleau
Furthermore, nothing prevents DropBox from using something like rsync to
do the updates, in which the sync is speeded up by only sending the
bytes that are changed.
What happens when two people change the same bytes, but make different
changes?
The second one to save replaces the first one, same as if both changes
are made on the _same_ system, unless both systems (maybe even one)
are offline, in which case the "conflicted copies" occur.
Post by Michelle Steiner
Many database systems handle this kind of conflict by locking out any
records that are being edited. If I'm editing a record, no one else can
edit it until I finish my work on it.
An excellent approach. I made no pretense that DropBox approach is
better. Merely that it does not discard data in the situation stated.
--
Wes Groleau

“There ain't nothin' in this world that's worth being a snot over.”
— Larry Wall
Bob Harris
2011-11-11 02:18:31 UTC
Permalink
Post by Wes Groleau
Post by Bob Harris
The only problem with a Dropbox approach is that it is limited to
entire file copies. If you have "Record" oriented data, where
data could be updated in multiple places between syncs, then an
entire file update will result in the most recent system to update
winning, and all other systems loosing their changes.
Not with DropBox. When you edit the file, the server is updated almost
immediately. When you log in to the other system, you get that update
immediately. IF for some perverse reason, you update this_file on Mac1
this_file(Mac2 conflicted copy)
this_file(Mac1 conflicted copy)
Furthermore, nothing prevents DropBox from using something like rsync to
do the updates, in which the sync is speeded up by only sending the
bytes that are changed.
an rsync partial copy of changed bits is fine if it is a flat
file. By that I mean just a simple linear list. But if the file
has indexes, hashes, btrees, etc... for fast access to records,
then an rsync approach of just copying part of the file is a fast
way to corrupting the file.

My day job is working on clustered file systems. As part of the
job I've seen what happens with uncoordinated access to a
clustered file. It almost always results in a corrupt file.

Dropbox is amazing, and I both use it and enjoy what it does.
However, I am also very aware what can go wrong if I perform
concurrent updates to record oriented data. Such as my 1Password
keychain file. And I do have my 1Password on Dropbox, but I'm
careful about updates when the system is off-line.
Wes Groleau
2011-11-11 07:05:25 UTC
Permalink
Post by Bob Harris
Post by Wes Groleau
Furthermore, nothing prevents DropBox from using something like rsync to
do the updates, in which the sync is speeded up by only sending the
bytes that are changed.
an rsync partial copy of changed bits is fine if it is a flat
file. By that I mean just a simple linear list. But if the file
has indexes, hashes, btrees, etc... for fast access to records,
then an rsync approach of just copying part of the file is a fast
way to corrupting the file.
This is not correct. If a file has has indexes, hashes, btrees, etc.,
then the program that changes the file will change the has indexes,
hashes, btrees, etc., and so rsync will include those changes in its
transfer.
Post by Bob Harris
My day job is working on clustered file systems. As part of the
job I've seen what happens with uncoordinated access to a
clustered file. It almost always results in a corrupt file.
I used rsync for years to keep two Macs identical. This includes
all software and database updates, even iTunes, mail, NetInfo,
gzips, ...

Both continued to work fine all that time.
Post by Bob Harris
Dropbox is amazing, and I both use it and enjoy what it does.
However, I am also very aware what can go wrong if I perform
concurrent updates to record oriented data. Such as my 1Password
keychain file. And I do have my 1Password on Dropbox, but I'm
careful about updates when the system is off-line.
Demo: Make a separate keychain file and get two computers
updated with it. Take both offline. Change something on each.
Put both online. When they both say DropBox has updated
everything, look in the directories. Do you see two versions,
with the filenames saying conflicted and identifying which computer
each came from?

If not, then I am wrong and it's just pure luck that it
happened to me many times.
--
Wes Groleau

Why the blind dog leading?
http://Ideas.Lang-Learn.us/BlindDog?itemid=3569
Bob Harris
2011-11-12 04:10:45 UTC
Permalink
Post by Wes Groleau
Post by Bob Harris
Post by Wes Groleau
Furthermore, nothing prevents DropBox from using something like rsync to
do the updates, in which the sync is speeded up by only sending the
bytes that are changed.
an rsync partial copy of changed bits is fine if it is a flat
file. By that I mean just a simple linear list. But if the file
has indexes, hashes, btrees, etc... for fast access to records,
then an rsync approach of just copying part of the file is a fast
way to corrupting the file.
This is not correct. If a file has has indexes, hashes, btrees, etc.,
then the program that changes the file will change the has indexes,
hashes, btrees, etc., and so rsync will include those changes in its
transfer.
If you have just one rsync talking to that file, you will not see
any problems. But if you have 2 clients running concurrent
rsync's to that same server file, then client A might be half way
through its copy when client B starts writing it stuff, and the
result is that A and B may perform writes that result in a
corrupted file.

chances are you do not have multiple clients performing rsync
partial file copies to the same file(s) with family members or
administrative assistants updating your shared calendar.
Post by Wes Groleau
Post by Bob Harris
My day job is working on clustered file systems. As part of the
job I've seen what happens with uncoordinated access to a
clustered file. It almost always results in a corrupt file.
I used rsync for years to keep two Macs identical. This includes
all software and database updates, even iTunes, mail, NetInfo,
gzips, ...
Both continued to work fine all that time.
But Apple has to design for situations with shared calendars,
conctact, systems being off-line when the changes occur and
possibly coming back online concurrently.

Again, I do not think you run multiple concurrent rsync operations
from different clients to the same server stored file.

I am not saying what you are doing is wrong, nor dangerous.
Besides liking Dropbox, I have been using rsync to backup my Mom's
iMac across the internet using rsnapshot which gives me a
TimeMachine like backup structure. I do the same at work to make
sure my development work is backed up on an hourly basis during
the day. I "Love" rsync. But it has its limitations, that in my
opinion, do not make it (or something modeled on rsync) a solution
for Apple's iCloud plans.
Post by Wes Groleau
Post by Bob Harris
Dropbox is amazing, and I both use it and enjoy what it does.
However, I am also very aware what can go wrong if I perform
concurrent updates to record oriented data. Such as my 1Password
keychain file. And I do have my 1Password on Dropbox, but I'm
careful about updates when the system is off-line.
Demo: Make a separate keychain file and get two computers
updated with it. Take both offline. Change something on each.
Put both online. When they both say DropBox has updated
everything, look in the directories. Do you see two versions,
with the filenames saying conflicted and identifying which computer
each came from?
If not, then I am wrong and it's just pure luck that it
happened to me many times.
I'm not saying you are wrong about Dropbox. I'm saying that
getting those conflicting files is a headache that Apple does not
want, as it will result in expensive support calls and unhappy
customers.
Wes Groleau
2011-11-12 20:00:31 UTC
Permalink
Post by Bob Harris
If you have just one rsync talking to that file, you will not see
any problems. But if you have 2 clients running concurrent
rsync's to that same server file, then client A might be half way
through its copy when client B starts writing it stuff, and the
result is that A and B may perform writes that result in a
corrupted file.
That may be. Or it may be that the author of rsync was a little smarter
than that.

It's not a problem when, as with DropBox, you are copying
whole files. If the file is corrupted, it's because the
program that wrote the file is buggy.
--
Wes Groleau

Be spontaneous … today
http://Ideas.Lang-Learn.us/BlindDog?itemid=3984
Wes Groleau
2011-11-12 20:02:29 UTC
Permalink
Post by Bob Harris
I'm not saying you are wrong about Dropbox. I'm saying that
getting those conflicting files is a headache that Apple does not
want, as it will result in expensive support calls and unhappy
customers.
I think that's probably true. But that's not what you said.
You said that concurrent updates would lose all but one of
the changes.

Or so it sounded to me.
--
Wes Groleau

Be spontaneous … today
http://Ideas.Lang-Learn.us/BlindDog?itemid=3984
Michael Vilain
2011-11-11 08:36:25 UTC
Permalink
In article
Post by Bob Harris
Post by Wes Groleau
Post by Bob Harris
The only problem with a Dropbox approach is that it is limited to
entire file copies. If you have "Record" oriented data, where
data could be updated in multiple places between syncs, then an
entire file update will result in the most recent system to update
winning, and all other systems loosing their changes.
Not with DropBox. When you edit the file, the server is updated almost
immediately. When you log in to the other system, you get that update
immediately. IF for some perverse reason, you update this_file on Mac1
this_file(Mac2 conflicted copy)
this_file(Mac1 conflicted copy)
Furthermore, nothing prevents DropBox from using something like rsync to
do the updates, in which the sync is speeded up by only sending the
bytes that are changed.
an rsync partial copy of changed bits is fine if it is a flat
file. By that I mean just a simple linear list. But if the file
has indexes, hashes, btrees, etc... for fast access to records,
then an rsync approach of just copying part of the file is a fast
way to corrupting the file.
My day job is working on clustered file systems. As part of the
job I've seen what happens with uncoordinated access to a
clustered file. It almost always results in a corrupt file.
Dropbox is amazing, and I both use it and enjoy what it does.
However, I am also very aware what can go wrong if I perform
concurrent updates to record oriented data. Such as my 1Password
keychain file. And I do have my 1Password on Dropbox, but I'm
careful about updates when the system is off-line.
Can't see how you do clustered file access without some sort of
distributed locking (e.g. DEC's distributed lock manager from their
original VMSclusters in the 1980s). But I guess that's what you meant
by 'uncoordinated access'.
--
DeeDee, don't press that button! DeeDee! NO! Dee...
[I filter all Goggle Groups posts, so any reply may be automatically ignored]
Bob Harris
2011-11-12 03:49:01 UTC
Permalink
Post by Michael Vilain
In article
Post by Bob Harris
Post by Wes Groleau
Post by Bob Harris
The only problem with a Dropbox approach is that it is limited to
entire file copies. If you have "Record" oriented data, where
data could be updated in multiple places between syncs, then an
entire file update will result in the most recent system to update
winning, and all other systems loosing their changes.
Not with DropBox. When you edit the file, the server is updated almost
immediately. When you log in to the other system, you get that update
immediately. IF for some perverse reason, you update this_file on Mac1
this_file(Mac2 conflicted copy)
this_file(Mac1 conflicted copy)
Furthermore, nothing prevents DropBox from using something like rsync to
do the updates, in which the sync is speeded up by only sending the
bytes that are changed.
an rsync partial copy of changed bits is fine if it is a flat
file. By that I mean just a simple linear list. But if the file
has indexes, hashes, btrees, etc... for fast access to records,
then an rsync approach of just copying part of the file is a fast
way to corrupting the file.
My day job is working on clustered file systems. As part of the
job I've seen what happens with uncoordinated access to a
clustered file. It almost always results in a corrupt file.
Dropbox is amazing, and I both use it and enjoy what it does.
However, I am also very aware what can go wrong if I perform
concurrent updates to record oriented data. Such as my 1Password
keychain file. And I do have my 1Password on Dropbox, but I'm
careful about updates when the system is off-line.
Can't see how you do clustered file access without some sort of
distributed locking (e.g. DEC's distributed lock manager from their
original VMSclusters in the 1980s). But I guess that's what you meant
by 'uncoordinated access'.
Our product does use a distributed lock manager. Without a DLM
(or similar means of coordinating writes, storage allocations,
etc...), the file system becomes corrupt very quickly.

As a former Digital employee, I am familiar with VAXclusters, as
well as Tru64 UNIX clusters, and their clustered file systems.

One of the problems I worked on back in the early '90s was a
customer that allowed their VAXcluster to become partitioned, so
that a subset of nodes thought they were the cluster, while the
remaining nodes thought they were the cluster, and both were
updating the file system. The result was a file system with
extremely corrupt user data.

My experience is different from Wes's, which is why I think
scaling up a Dropbox style solution by Apple would result in a
huge support issue for Apple, even if there are just a fraction of
1% resulting in update conflicts, it would still be a very large
number of customers having conflict issues.

This is all just a personal opinion, based on working with
clustered file systems since the late '80s, both as a user and as
a developer.
Michael Vilain
2011-11-12 05:51:22 UTC
Permalink
In article
Post by Bob Harris
Post by Michael Vilain
In article
Post by Bob Harris
Post by Wes Groleau
Post by Bob Harris
The only problem with a Dropbox approach is that it is limited to
entire file copies. If you have "Record" oriented data, where
data could be updated in multiple places between syncs, then an
entire file update will result in the most recent system to update
winning, and all other systems loosing their changes.
Not with DropBox. When you edit the file, the server is updated almost
immediately. When you log in to the other system, you get that update
immediately. IF for some perverse reason, you update this_file on Mac1
this_file(Mac2 conflicted copy)
this_file(Mac1 conflicted copy)
Furthermore, nothing prevents DropBox from using something like rsync to
do the updates, in which the sync is speeded up by only sending the
bytes that are changed.
an rsync partial copy of changed bits is fine if it is a flat
file. By that I mean just a simple linear list. But if the file
has indexes, hashes, btrees, etc... for fast access to records,
then an rsync approach of just copying part of the file is a fast
way to corrupting the file.
My day job is working on clustered file systems. As part of the
job I've seen what happens with uncoordinated access to a
clustered file. It almost always results in a corrupt file.
Dropbox is amazing, and I both use it and enjoy what it does.
However, I am also very aware what can go wrong if I perform
concurrent updates to record oriented data. Such as my 1Password
keychain file. And I do have my 1Password on Dropbox, but I'm
careful about updates when the system is off-line.
Can't see how you do clustered file access without some sort of
distributed locking (e.g. DEC's distributed lock manager from their
original VMSclusters in the 1980s). But I guess that's what you meant
by 'uncoordinated access'.
Our product does use a distributed lock manager. Without a DLM
(or similar means of coordinating writes, storage allocations,
etc...), the file system becomes corrupt very quickly.
As a former Digital employee, I am familiar with VAXclusters, as
well as Tru64 UNIX clusters, and their clustered file systems.
One of the problems I worked on back in the early '90s was a
customer that allowed their VAXcluster to become partitioned, so
that a subset of nodes thought they were the cluster, while the
remaining nodes thought they were the cluster, and both were
updating the file system. The result was a file system with
extremely corrupt user data.
My experience is different from Wes's, which is why I think
scaling up a Dropbox style solution by Apple would result in a
huge support issue for Apple, even if there are just a fraction of
1% resulting in update conflicts, it would still be a very large
number of customers having conflict issues.
This is all just a personal opinion, based on working with
clustered file systems since the late '80s, both as a user and as
a developer.
If (and it's a big if) Apple uses some sort of client authentication and
_stateful access_, I think you'll get coordinated access. DLM + RMS
(DEC record management on top of the file system) allowed for concurrent
updating _at the record level_ throughout the cluster. When Sun started
working on clustering, I just had to sigh. Sometimes Sun liked
reinventing the wheel. I'm also a former employee but worked with
customers out in the field rather than in development back at the Mill
or Nashua (RIP Uncle Ken 5/14/2011).

rsync and nfs are stateless and so won't work. Apple (or whomever)
would have to setup some sort of remote client that signs onto the
network server and the server would have to keep track of that
connection information beyond authentication. It would require that
server-based lock manager to be robust, fault tolerant, and scale well.
A tall order, IMO. I'm not sure how Dropbox does concurent access, if
at all. Even with NFS-accessed files, whoever wrote the file last wins.
That wasn't so on VMS. If a process on some node on the cluster write
locked a record, others could only read it. Attempting to write the
file would fail with a locking error.
--
DeeDee, don't press that button! DeeDee! NO! Dee...
[I filter all Goggle Groups posts, so any reply may be automatically ignored]
Wes Groleau
2011-11-12 20:09:01 UTC
Permalink
Post by Michael Vilain
If (and it's a big if) Apple uses some sort of client authentication and
_stateful access_, I think you'll get coordinated access. DLM + RMS
(DEC record management on top of the file system) allowed for concurrent
updating_at the record level_ throughout the cluster. When Sun started
Can't do that when you don't know the record structure of the file.
Post by Michael Vilain
A tall order, IMO. I'm not sure how Dropbox does concurent access, if
at all. Even with NFS-accessed files, whoever wrote the file last wins.
As I said, not so with DropBox.
Post by Michael Vilain
That wasn't so on VMS. If a process on some node on the cluster write
locked a record, others could only read it. Attempting to write the
file would fail with a locking error.
Here you risk the problem Bob warned against. Unless that process
locks ALL records pertinent to its change, while it is writing one
record, another could make changes in a different record that partially
depend on what the first locked record said before the write.
--
Wes Groleau

Be spontaneous … today
http://Ideas.Lang-Learn.us/BlindDog?itemid=3984
Paul Sture
2011-11-13 00:07:54 UTC
Permalink
Post by Wes Groleau
Not with DropBox. When you edit the file, the server is updated almost
immediately. When you log in to the other system, you get that update
immediately. IF for some perverse reason, you update this_file on Mac1
this_file(Mac2 conflicted copy)
this_file(Mac1 conflicted copy)
I've had that a couple of times, though in my case I think it was down to
editing a file while offline.
Post by Wes Groleau
Furthermore, nothing prevents DropBox from using something like rsync to
do the updates, in which the sync is speeded up by only sending the
bytes that are changed.
I'm not sure whether it uses rsync/similar technology or not, but given
the speed of the thing I suspect it does.
--
Paul Sture
Tom Harrington
2011-11-09 16:44:04 UTC
Permalink
Post by B***@fractious.net
Post by Michelle Steiner
That's still nowhere near enough - it needs to be general-purpose, not
just iWork documents, though that'd be a start.
Each app has to become iCloud aware and use the iCloud APIs.
Ugh. Remember - we are talking about Macs here, not iOS
devices. On iOS apps don't have a common filesystem. On
the Mac, there's no reason not to take advantage of it.
If you're talking about iCloud and _not_ considering iOS devices, then
you are massively missing the point.
Post by B***@fractious.net
Post by Michelle Steiner
Seriously, Apple's just way behind on this. And Jobs knew it -
Apps have to be DropBox aware too, right?
Not at all. On the desktop, any cloud system which either
uses sync or which attaches as a regular old filesystem
may be written to by any application.
On iOS on the other hand, apps must have Dropbox support built in. If
you never use iOS then maybe this doesn't matter to you.
Post by B***@fractious.net
Anything I'm actively working on lives either in a directory
which gets synced via Dropbox or Wuala right now.
Perhaps I misread the whole iCloud thing, but my impression
was that it should ultimately allow something similar. At
this point, it looks to me like it'll be useful only for
address book and calendaring. Nice but no wow.
There's an awful lot of open ground between the idea that iCloud would
match Dropbox's feature set as opposed to the idea that it's only useful
for contacts and calendars. Nevertheless it's clear you have made up
your mind.
--
Tom "Tom" Harrington
Independent Mac OS X developer since 2002
http://www.atomicbird.com/
B***@fractious.net
2011-11-09 17:03:37 UTC
Permalink
Post by Tom Harrington
Post by B***@fractious.net
Post by Michelle Steiner
That's still nowhere near enough - it needs to be general-purpose, not
just iWork documents, though that'd be a start.
Each app has to become iCloud aware and use the iCloud APIs.
Ugh. Remember - we are talking about Macs here, not iOS
devices. On iOS apps don't have a common filesystem. On
the Mac, there's no reason not to take advantage of it.
If you're talking about iCloud and _not_ considering iOS devices, then
you are massively missing the point.
I'm considering both. Sounds like you're missing the desktop.
Post by Tom Harrington
On iOS on the other hand, apps must have Dropbox support built in. If
you never use iOS then maybe this doesn't matter to you.
Actually, since Apple added the "Send document to..." functionality,
that's not really true. Some apps are natively dropbox aware,
but they don't need to be in order to be able to use it.
Post by Tom Harrington
There's an awful lot of open ground between the idea that iCloud would
match Dropbox's feature set as opposed to the idea that it's only
useful for contacts and calendars. Nevertheless it's clear you have
made up your mind.
Not at all. I'm looking forward to how iCloud develops (though
I'd be a lot more eager if they'd (a) not gotten rid of the
existing photo galleries; and (b) they'd support 10.6). At
this point, though, it looks like a big marketing failure.
I work with Macs all day long and they haven't made it clear
to me what's going on. If they haven't gotten me on board,
they're going to have a hell of a time with the wider public.
Best I can tell, they were just way too premature with telling
us about it.

I don't have much of a choice regardless. I will be using
iCloud. That's a given. I'd like to see some reason to be
excited about it. So far, nothing that looks like any kind
of an improvement over what I'd already had from Apple.
Maybe they'll actually make it more clear what it's going to
mean for us beyond the address book and calendars, but they
really have failed with the marketing message here.
--
Plain Bread alone for e-mail, thanks. The rest gets trashed.
Michelle Steiner
2011-11-09 17:36:31 UTC
Permalink
Post by Tom Harrington
Ugh. Remember - we are talking about Macs here, not iOS devices. On
iOS apps don't have a common filesystem. On the Mac, there's no
reason not to take advantage of it.
If you're talking about iCloud and _not_ considering iOS devices, then
you are massively missing the point.
We're talking about apps on the Mac accessing iCloud. Right now, to get an
iWork file onto iCloud, you have to to through the iCloud web site, or use
the undocumented "Mobile Documents" folder. Unlike with iOS devices, the
documents are not automatically placed in iCloud.

As I understand it, he's saying that iCloud should be able to work just
like DropBox does, with iCloud watching a folder, and anything saved into
that folder or its sub folders would automatically be put in the cloud.

I'm saying that I believe that Apple is going the route of iCloud aware
applications, so that whenever you save a document, regardless of what
folder it's saved to, it would automatically put that document in the cloud.
--
Tea Party Patriots is to Patriotism as
People's Democratic Republic is to Democracy.
B***@fractious.net
2011-11-09 17:58:13 UTC
Permalink
Post by Michelle Steiner
As I understand it, he's saying that iCloud should be able to work just
like DropBox does, with iCloud watching a folder, and anything saved into
that folder or its sub folders would automatically be put in the cloud.
Not necessarily precisely the same way, but some way that's
transparent and works with everything. What it will be, I
don't know. I'd be pretty impressed if it was something as
simple as some kind of filesystem flag which lets the OS know
that a given doc or folder should be cloud-ified. Pushing the
apps to have to be updated to deal with it - when even Apple
hasn't managed that yet - seems unfortunate.
Post by Michelle Steiner
I'm saying that I believe that Apple is going the route of iCloud aware
applications, so that whenever you save a document, regardless of what
folder it's saved to, it would automatically put that document in the cloud.
It looks like you're probably right, at least based on my reading
of this page:

http://www.apple.com/icloud/features/documents.html

Noting that except for the very end of that page, it's apparently
all iOS apps. And at the end, they point out that on the desktop
you can "easily" use your browser to do it. That'll make for a
nice easy workflow. If they have a better plan, I just wish
they'd let us know what it is.
--
Plain Bread alone for e-mail, thanks. The rest gets trashed.
Tom Harrington
2011-11-08 17:50:22 UTC
Permalink
Post by B***@fractious.net
Post by Tom Harrington
Post by B***@fractious.net
Post by Michelle Steiner
You have to manually upload documents to iCloud from the Mac; it does not
There are some great alternatives which do automatically sync
parts of your filesystem between computers (and including access
via iOS devices). iCloud clearly isn't the answer, but
DropBox, Wuala, SugarSync and a few others may fit the bill.
iCloud is the answer to a different question than those services.
iCloud is apparently *supposed* to be the answer to the question
of getting your documents into the 'cloud' (as well as the things
it actually does well like your addressbook and calendars).
If you have to manually upload your documents to it (as Michelle
is quoted above saying), then iCloud fails as the answer to
that part of the question.
Only if you assume that using the "cloud" means that all of your data is
uploaded whether you want to or not. Some might well consider it a
feature that you get to choose. If you don't, iCloud may not be for you,
but that's because it's not attempting to solve the problem you want
solved.

The current situation for iWork exists only because Apple has not yet
updated those apps to be iCloud-aware on Mac OS X. I don't know why this
is the case, but it's like this because the current iWork is the same
version that was current before iCloud existed. In practice apps using
iCloud will not have anything like a manual upload process, nor will
they require a web browser. It'll be (at most) more like tapping a
checkbox marked "Store in cloud" and just having it work from that point
forward.
Post by B***@fractious.net
One of the problems is that it just isn't clear what iCloud is
or is supposed to be doing for us. The addressbook and calendar
syncing is nothing new. Photostream may be a good thing, but
I really haven't much interest in it - I'm quite happy with my
MobileMe galleries (which are going to go away). So what's left?
In my opinion, Apple has failed to really wow us with anything
really groundbreaking in iCloud, at least as of yet. Maybe
photostream and music match will really make it stand out, but
it's not clear.
When I edit a Keynote document on my iPad, and my changes automatically
appear in Keynote on my iPhone, it seems like a pretty compelling new
feature. Your mileage may vary.
Post by B***@fractious.net
Meanwhile, other third party companies have come in and done
what Apple hasn't -- made it easy to keep your documents in
the cloud in a way that they are immediately and easily useful
on multiple machines and platforms without having to do anything
extra like uploading them via web page. Apple has basically
managed to make addressbook and calendars work about that well,
but never general documents.
Jobs tried to buy DropBox out - he saw how good it was, even though
he called it a "feature" not an app. Maybe it is just a feature,
but nobody else seems to have managed to make anything else work as
easily and transparently, nor gotten loads of third-party apps to
use it so well. There are others that work just about as easily
but have different features (ie. SugarSync and Wuala, both of
which have a lot of overlap with DropBox).
That's true. However, iCloud as currently incarnated is not seriously
attempting to compete with those services. The comparison is completely
irrelevant. You might as well complain that Pages fails to measure up to
Photoshop.
--
Tom "Tom" Harrington
Independent Mac OS X developer since 2002
http://www.atomicbird.com/
Michael Vilain
2011-11-08 06:05:55 UTC
Permalink
Post by Michelle Steiner
Post by Skylamar
I don't own an iOS device. I just own a Mac. I also own Pages, but the
'08 version. So, assuming I buy the latest version of Pages, I'm
- Can ICloud display iWork documents on its website?
It can display that the document is there, but not the contents of the
document. But so far as I know, there's no public folder in iCloud as
there is in Mobile Me. So you can't use iCloud to distribute documents to
other people.
Post by Skylamar
- Is there a way to limit which iWork documents my Mac syncs with
iCloud? For instance, I'm looking for employment and I'm sending out a
bunch of different cover letters, written in Pages, every day and I
wouldn't want all of them synced with iCloud.
You have to manually upload documents to iCloud from the Mac; it does not
automatically sync documents like the iOS devices do.
Pages '09 has a Share menu which allows you to upload documents to
iWork.com. I don't know if that's still in use or part of an older
document sharing strategy. If you translate documents to PDF, you can
make them available via Google Docs. Or upload them to your shared
directory on your web server.
--
DeeDee, don't press that button! DeeDee! NO! Dee...
[I filter all Goggle Groups posts, so any reply may be automatically ignored]
Continue reading on narkive:
Loading...