Why a server load?

[Patrick Burleson]

Pardon me if I'm missing some "bigger" picture element here, but why
does the SpanningSync software need to connect back to the "home"
servers to do the syncing? Why isn't it just going directly against
Google Calender?

Since I'm sedning my username/password to your servers, what's being
done to protect them from prying eyes?

Thanks,
Patrick

[txra...@gmail.com]

It really does not need to connect back to home. That is just how
they
have developed it. This way they can charge a monthly/yearly
subscription
fee. They feel the control is better for the customer. :-(

Have not really heard what measures they are taking with the username/
paswords either.

I am on the edge right now because of these two issues.

[cwood]

I've talked about the reasoning behind this decision in several places
(comments to our blog, comments on other blogs, this Google Group) but
clearly this is an important issue to some users and therefore
deserves a thorough discussion. I'll work on that, but for the time
being here's the short version:

Regardless of where the actual sync code lives, there must be some
server component involved if for nothing else than making sure
multiple Macs aren't making changes to the same Google calendar at the
same time. We call this "sync locking", and basically it protects your
Google calendars from corruption. The lock information for any given
calendar has to be available to all clients making changes to that
calendar, so in order for us to allow multiple Macs in multiple
locations to sync to the same Google calendar, we have to have a
server-based sync lock system.

Now we could put the locking code on the server and the syncing code
on the client, but we chose not to for a variety of reasons, probably
the most important of which is flexibility. Right now Spanning Sync
only syncs between Macs and Google Calendar, but we have plans to
introduce a version that syncs between Google Calendar and
Salesforce.com. Since those are both server-based systems, the sync
engine has to be server-based as well. If we had written the sync
engine for Spanning Sync to live on the cilent, we'd have to rewrite
it for our next product. We decided to take the hit on operational
cost (our server bill isn't cheap) in order to gain that flexibility.
This architecture will also let us do some exciting things we can't
talk about publicly yet, but if you look at the announcements on our
blog you might get an idea of what they could be.

Finally, there's the issue of our users' Google account information
going through our servers. We never store your account information
anywhere other than the Keychain on your Mac, but our servers do
handle that information during the sync process. This isn't ideal,
because it makes our users rely on us to not do anything nefarious
with that information. Our Security and Privacy Statement at <http://
spanningsync.com/security/> makes it clear that we don't use that
information for anything other than accessing Google services on our
user's behalf, but again our users are forced to trust us.

The good news is that there's a solution, but unfortunately it's not
yet complete. Google has an authentication mechanism called AuthSub
that is made specifically for this case. The user tells Google that
Spanning Sync is allowed to access Google Calendar on his behalf, and
Spanning Sync doesn't ever see the user's password. Unfortunately
AuthSub is not yet available for Google Apps for Your Domain, which is
a requirement for a lot of our users. As soon as Google finishes
implementing this mechanism for all Google accounts, we'll switch to
it. If you're not comfortable with our handling your Google account
information, you should wait until we switch to the AuthSub mechanism.
We promise not to take it personally. :-)

Whew, didn't really wind up being the short version, did it? I'll post
that as a FAQ, and we can continue the discussion here. I'll
incorporate my answers to any questions anyone may have in the FAQ.

Regards,
Charlie

[cwood]

OK, I've added a link to this thread on the updated FAQ at <http://
blog.spanningsync.com/2006/11/frequently_aske.html>.

Regards,
Charlie

[Patrick Burleson]

Charlie,

Thank you for that very informative response. And thanks for posting a
link on the site. That will certainly help other users find the answer
to this question.

After I sent my question, I began to wonder about the design decision
and came to the same conclusions. My biggest one was "they could
implement their own custom API that hides changes to the Google API,
thus not having to update the client every time Google changes the API
)".

As for the username/password, the current setup is certainly not
ideal. While you wait for Google to finish the auth code for GAFYD,
maybe you could make a preference for those of us not using GAFYD to
use the other authentication method?

Patrick

[cwood]

Patrick,

Actually your "API translation" thought is an accurate one. The Google
API is an ever-moving target (usually moving from how it actually
works to how it's supposed to work, luckily) and we're able to make
changes on the server to allow for this without distributing new
clients. Of course, we've been making changes to the client so quickly
that users don't actually benefit much from it during the beta. But
once we ship v1.0, we certainly don't intend to issue a new version
once a week. :-)

As for optional GFAYD support, we've considered it. If Google doesn't
have AuthSub support built in by the time we start working on the
first post-v1.0 version, we may implement your idea.

Regards,
Charlie

[jay.j...@gmail.com]

This seems like a pretty crappy implementation on Google's side.
Shouldn't the locking mechanism live in their api, especially if
concurrent calls can cause corruption? (alliteration not intended, but
enjoyed)

Here's my appeal to the spanning sync folks. I'll pay good money for
an application that talks directly to Google calendar from my Mac (no
middle-man) (and multiple macs are good too). I don't care about any
fancy features or who else you want to release a google calendar
syncer to. I want to sync to my calendars directly and not worry
about anyone else's privacy policy besides Google's. I want to pay a
one time license fee, not a recurring subscription. I am happy to
upgrade my client when Google changes their api.

I'm running the beta now, but I will have to consider whether or not I
will purchase the full version when it comes out.

[dunha...@gmail.com]

On Feb 5, 11:57 am, "jay.jans...@gmail.com" <jay.jans...@gmail.com>
wrote:

> This seems like a pretty crappy implementation on Google's side.
> Shouldn't the locking mechanism live in their api, especially if
> concurrent calls can cause corruption? (alliteration not intended, but
> enjoyed)

The google data api has optimistic locking built into their API. The
documentation is at:
http://code.google.com/apis/gdata/reference.html#Optimistic-
concurrency

The locking is done on a record by record basis, so it may make life a
little harder on syncing software, but I don't see why it wouldn't be
possible.

Either way, I guess it's their design decision, even though it's a
show stopper for me. but google's ical feed is good enough for now.
Eventually, someone (maybe google?) will put together an isync plugin
that works the way we want.