Does it talk directly with Google?
TimBo
of interest to all...
Does/will this sync directly from iCal to Google, or does it go through
another server?
Personally, if it goes through another server, I'll be looking for
another solution unless the price is extremely low. If it speaks
directly to Google, without a "middle-man", then I'm down for it!
cwood
Mac and a service that runs in our datacenter, which in turn talks to
Google. We chose this architecture for several reasons.
First and foremost it allows us to constantly improve the system--by
fixing bugs, adjusting to the frequent subtle changes in the Google
Calendar API, and adding new functionality--all on the server, without
forcing our users to install updates on their machines.
It also gives us the ability to spot and solve problems sometimes
before our users even notice there's something wrong.
Finally, it leaves open the possibility providing sync services between
online services. For instance, our next product will synchronize
calendars between Google and Salesforce.com.
We appreciate the privacy and security concerns of our users and take
steps to make sure that their private data stays private. We don't
store any calendar data; we only process it. Our background is in
providing similar services for our customers' most sensitive corporate
data (see http://spanningsalesforce.com), and we consider each user's
calendar data to be no less important.
David Chartier
Personally, if it goes through another server, I'll be looking for
another solution unless the price is extremely low. If it speaks
directly to Google, without a "middle-man", then I'm down for it!
I find the worry about a 'middle man server' pretty ironic, especially since we're discussing this through Gmail/Google's Group servers, and we're talking about a Google Calendar service. The company who's pioneered data retention for advertising and marketing purposes.
Spanning Sync isn't going to peek into our personal and business lives, and when you think about it, they aren't the only ones who might have access to our data. If you have a .Mac account, that means Apple knows when you've scheduled your next business meeting and when to pick up Sally from soccer practice.
This is a legitimate company, and if anything their access to your data should increase the value of the product, given how much is theoretically at stake, and the responsibility they have in protecting your stuff.
Do you want to pay for a $5 dollar body guard, or a $100 body guard?
Not to say that I think Spanning Sync should cost $100, mind you. :)
--
David Chartier
--
My work:
The Unofficial Apple Weblog: http://www.tuaw.com/
Download Squad: http://downloadsquad.com
My play:
1FPS: http://www.dcharti.com/blog/
Vox: http://dcharti.vox.com
Tyler Hall
act as a middle man. Why? I don't want to deal with a subscription fee.
I don't want to worry about SS's servers being available each time I
sync my calendars. I get the impression that Spanning Sync is used to
dealing with "companies" rather than individual Mac users. (The types
of users who flock to programs like TextMate, AppZapper, Disco,
Transmit, and NetNewsWire.) I don't want a program that "leaves open
the possibility providing sync services between
it well. If you want me to use another one of your services, that's
fine. Sell me another product when the next one is ready.
I appreciate Spanning Sync's desire to catch bugs and implement fixes
transparently on the server side without users noticing, however many
of the Mac applications I use on a daily basis are constantly checking
for updates - and most of them install themselves automatically after
prompting me for approval. I don't think you're going to turn off users
by releasing an occasional update. If anything, I think they'd
appreciate the fact that you're actively working to improve their
experience.
> I find the worry about a 'middle man server' pretty ironic, especially since
> we're discussing this through Gmail/Google's Group servers, and we're
> talking about a Google Calendar service. The company who's pioneered data
> retention for advertising and marketing purposes.
I see the irony (there's plenty), but there is a slight difference.
First off, using Spanning Sync's servers adds a third party to the
conversation where previously it was just between the user and Google
(not counting the network providers of course). Also, I have no choice
but to trust Google. They're getting bigger and scarier every day, but
so far they haven't given me a reason not to trust them. I don't trust
Spanning Sync yet. (I know I'm holding them to a double standard by not
giving them the chance to earn my trust, but that's just the way it is
for smaller companies I haven't dealt with before.)
Justifying the middle man approach by arguing "it leaves open the
possibility providing sync services between
online services" doesn't make sense to me. Currently, (from what I've
seen) the preference pane doesn't mention anything regarding syncing
with other online services. Therefore, to add that feature, Spanning
Sync would have to release an update for their users to install -
something which they want to avoid doing. Until that happens why bother
going through their servers? Let the preference pane talk directly with
Google. Or, better yet, offer two versions. An inexpensive one that
takes the direct approach, and a corporate edition with all the other
bells and whistles :-)
Sorry, but playing the middle man will be a deal breaker for me.
Tyler Hall
On Nov 2, 10:30 am, "David Chartier" <dcha...@gmail.com> wrote:
> On 11/2/06, TimBo <tim...@gmail.com> wrote:
>
>
>
> > Personally, if it goes through another server, I'll be looking for
> > another solution unless the price is extremely low. If it speaks
> > directly to Google, without a "middle-man", then I'm down for it!I find the worry about a 'middle man server' pretty ironic, especially since
TimBo
security.
Simply put, if it involves a subscription, I'm out. One time flat fee,
no reliance on a 3rd party system that may or may not be here a year
down the road, forget it.
I'll lay odds that before the middle of 2007, Google will have a (beta)
application available for free that will sync iCal with Google
Calendar. Not to mention something to sync Google Cal with Outlook for
the Windows users.
David Chartier
On a broader scale, considering the demographic this app is going to appeal to, I"m willing to bet most of your users aren't going to mind the occasional update either. Most users who seek out this kind of functionality are used to the application update process, and on TUAW we've blogged services/frameworks that allow developers to build self-updating into the application itself. I believe it's called Sparkle, and Adium is a good end-user example of it; the app tells you there's an update and allows you to download or ignore. if you download, it installs the update itself, and prompts you to restart the app. No fuss, no disk images, no zip archives or manually replacing files buried in some app support folder somewhere.
David Chartier
--
My work:
http://DownloadSquad.com
My play:
http://www.dcharti.com/blog/
http://dcharti.vox.com
TimBo
should wait for or rely on Google to ship something that does this. On
the contrary... If you can beat them to the punch and keep the feature
set a notch or 2 above whatever Google comes out with, you'll be able
to build a user base and make money off of it.
parakeet
service.
Bear in mind that other services I pay for (Blinksale, FeedBurner
TotalStats, FeedLounge) cost US$5pm, Strongspace slightly more. It
would *have* to be a low monthly fee.
David Chartier
Unfortunately, a lot of those other services are subsidized by advertising; Spanning Sync doesn't look like it has much opportunity for this, since it runs as a background daemon calling Google Calendar and simply syncing your items transparently. There are no webpages in between with which Spanning Sync can display ads.
There's also the topic of use and value - none of those other services have anything to do with what Spanning Sync is capable of. Simply saying "well I pay $5 for this completely unrelated online service" doesn't bear a whole lot meaning to Spanning Sync.
--
My work:
Ricky
this is worth about $10-15. Total. There is no reason a middle-man
server should be required. I would not get near this app with a
10-foot pole if it involved any type of monthly or yearly subscription
fee. $5 is not in any way a low fee for this type of app. That's $60
per year for goodness sakes! The only Mac app I've bought that cost
more than $39 was Final Cut Express HD. Even the iLife suite costs $49
(with my student discount). Unless you can provide a stand-alone
solution, or guarantee that there will be no subscription fee, I'm out.
andr...@gmail.com
also the worry of your servers being hacked and personal information
being leaked, no matter how remote. I trust Google with my
information! While they use it to do targeted advertising and anything
else I'm confident that it isn't getting into the wrong hands. For a
company of their size (and stock market value) it would be a PR
disaster to have major leaks or obvious use of "private" information
for other purposes.
For this solution it doesn't seem that there's any need for you to do
the processing on your server. I assume you're talking to a public API
at Google and the Mac is sending raw information to you. Why not do
it all in a single client side app.
Plus: if you're going to offer a subscription model through your
servers there's even more chance that someone will come along with a
single solution that doesn't require the servers and make this tool
obsolete.
If this really turns out to be the model I just might go about writing
this myself and make it free.
Jon
neilio
involved a hosted solution; this decision really does make very little
sense to me. I don't want to have to rely on *two* systems being online
and functional before I can sync my data. From a logical standpoint
this really does seem like more of creating an ongoing source of
revenue rather than a user / customer-centric decision. How does having
my data pass through your servers improve my experience?
Short answer: it doesn't. Thousands of software developers fix issues
every day and push out updates to their software without forcing users
to subscribe to a hosted service - there's no reason for this solution
to be any different.
cwood
service-oriented architecture affects the user experience: continuous
improvement. Let me give you an example.
Yesterday we pushed v1.0b2 (106) of the client software to a new group
of beta testers. Within minutes, one of them had run across a bug. He
didn't report it, but since the request and response went through our
servers, our own error reporting function caught it and alerted us.
Within minutes we were able to fix the bug in the server code and push
the fix to the live servers. When the user synched again 10 minutes
later, the bug had been fixed. He literally never had to lift a finger.
If Spanning Sync didn't include a service component, we wouldn't have
discovered the bug until someone decided to report it, and once we had
fixed it, every one of our users would have had to install a new
version of the software. Since we wouldn't want to build and distribute
a new version every time any individual bug was fixed, they'd be forced
to live with that bug until the next beta release. But our
service-oriented architecture allows us to continuously improve the
quality of the service without interruption to the user. That's a big
deal to us.
Regards,
Charlie
txra...@gmail.com
I can understand where you are coming from with the service oriented
architecture but I guess I would question why you are getting
hesitation from us accepting that architecture if it is so beneficial
to us. It is almost a case of customers telling you what they want and
you telling the customer what they want. What do you think the results
of an open poll of your customers would be if you were to ask them
whether they wanted your Service-oriented architecture or stand-alone
application that talked directly with Google? Might be interesting.
I'm cheering for you either way!
txranger
cwood
tell our users what they want. I'm just explaining the rationale behind
a decision thawas made at the outset of the project. The majority of
people I've talked to about the issue don't have a strong opinion one
way or the other, but then again the majority of people I've talked to
aren't active in this discussion group.
We absolutely value the feedback. That's why we created this discussion
group in the first place. And we absolutely value passionate users.
Please keep the feedback coming. We read every bit of it and take it to
heart.
Regards,
Charlie
andr...@gmail.com
releases. If you have bugs that are that serious the beta should not
have gone out. Why I appreciate you don't have a department of
testers etc, but surely you have multiple server and some dummy
calendars though which you can automate most of the user actions.
If you're looking for a good testing tool, then look into Eggplant.
I've used some of this kind of testing and it really does work
http://www.redstonesoftware.com/
neilio
> of beta testers. Within minutes, one of them had run across a bug. He
> didn't report it, but since the request and response went through our
> servers, our own error reporting function caught it and alerted us.
> Within minutes we were able to fix the bug in the server code and push
> the fix to the live servers. When the user synched again 10 minutes
> later, the bug had been fixed. He literally never had to lift a finger.
This sounds like you need to be more confident and stringent in your
beta testing / pre-release QA rather than a benefit for the actual
release-using customer. If your release-quality software is going to
require so many frequent updates that it needs to be remotely hosted
there's a bigger issue than just a poorly thought out business plan.
I'm not trying to be an ass about this, but let's be 100% honest here:
we're dealing with a system to sync calendar data between a computer
and a **free** service. There's absolutely no reason that this needs to
be so complex that it requires client and server-based software when
there's an API available.
Frank Rosquin
migrate it all to the client?
I have to agree on this point, I do not like the middle man.
Not because if privacy issues, but because I do not want a subscription
based service, I want to buy an app. And I want to know that said app
keeps working if for whatever reason your company goes bankrupt/your
server explodes/someone trips over the power cord/whatever...
While this is something I'd really like, I personally will not pay for
a subscription, and the middle man makes me very doubtfull about
spending my €
David Chartier
I have to agree on this point, I do not like the middle man.
Not because if privacy issues, but because I do not want a subscription
based service, I want to buy an app.
Louis G
> All things considered, I prefer the middle man. Maybe I'm just
> getting old (26), but I'm getting a little tired of endless
> application updates and 1.0.2.45 beta 15 built #4198 version bumps,
> so the way they're rolling here is almost a welcome change.
But you still have a client side application to keep updated.
David Chartier
But you still have a client side application to keep updated.
Alex
has worked in the past and is working currently.
Everyone is very used to doing this, ESPECIALLY BETA TESTERS. So your
argument above of that one incident doesn't really stand.
Why is it so hard?
The Dirty way:
fix bug, recompile, update your website with new download. Send RSS or
email notification of update
The Clean way:
Have the client code (especially for the beta) phone home every 24 hrs
looking for new updates. Fix bug, recompile, update self-update
service. On the users side, we see a "New version available, Yes/No to
update".
The Convoluted way:
Component-ize your code so half of it is on a client and the other half
is on a server. You still have to update the client using the Dirty way
(albet less frequently) but you make updating the core of the App very
easy on your end at the expense of pissing off your users and loosing
business.
Trust me, most people have no problem getting an update. It's actually
part of the Mac user experience and I personally always love it. And
during the beta period, christ... who cares.. participating in a beta
implies reinstalling the app a bazillion times.
sheeeesh.
Ricky
> Have the client code (especially for the beta) phone home every 24 hrs
> looking for new updates. Fix bug, recompile, update self-update
> service. On the users side, we see a "New version available, Yes/No to
> update".
Right, and with Sparkle available
(http://andymatuschak.org/pages/sparkle) for FREE to any Cocoa
developer, there is no excuse for a clean auto-update. I have many
apps that use the Sparkle framework to auto-update, and it works
flawlessly. As a beta tester, I wouldn't mind at all if it updated
itself many times a day. As the app progresses and becomes more stable
and mature this will slow down to probably once per week at the most.
I could even handle once per day if necessary. I just don't want a
middle man. It's not necessary.
stick...@gmail.com
google. I was one of the first to sign up for the beta but ditched it
when i found out how it works.
And this talk about google 'just playing with the API', keep in mind
calender is still a beta product and the API wont freeze till calender
is released, google has a right to change the API during this period.
Perhaps this just isn't the time for the spaningsync product if
breakage is as often as it is being mentioned and they are trying to
integrate with a beta product. And if we are beta testers, we are used
to (or should be) updating our app everyday and even having it wipe out
our calender from a programing error.
Don't get me wrong, i totally love the idea of this app and will buy it
in a second if it is a standalone app even if it automatically updates
every so often for what ever reason.
ALK
most certainly am not paying more than $10-15 one time payment for this
software.
I understand and apreciate the thoughts that creators of this software
have about catching the issues and not causing any users discomfort by
"not forcing" them to re-install the software when the new version
comes up but that's just not enough.
When i use google's email, calendar, chat, forum i entrust my personal
information to this company and i do so with understanding that the
exchange is only between the two parties. Having Spanning Sync merely
"process" the information does not help with my privacy concerns.
Being somewhat familiar with software architecture i tend to question
the motives of anyone that would create a software that instead of
communicating directly client to server would have designed a "middle
man", no matter how noble the idea of fixing the bugs found in the
process is.
In short, i will not be using this software and will immediately look
for alternative means of accomplishing sync. Furthermore i'm sure
google will release something soon enough that will do all of these
things and without a "middle man", sort of like what happened with
Google Notifier.
-ALK
cwood
It's certainly your prerogative to use or not use our service, but I
must address your calling our motives into question.
Spanning Partners, the company behind Spanning Sync, has a history of
securely processing our customers' most valuable data, including not
only personal and business calendars but also sales, support, and
marketing data. We take security and privacy very seriously. We publish
and adhere to strict security and privacy guidelines, which are
available online at http://spanningsync.com/security.
You may call into question our software architecture choices, but if
you have any question as to our motives, ethics, or values I suggest
you talk to any of our customers past or present. Or if you like, I'd
be happy to speak with you directly to address your concerns. You can
reach me by email at charli...@spanningpartners.com or by phone at
+1-512-217-6551.
Regards,
Charlie
--
Charlie Wood
Principal, Spanning Partners, LLC
tvongaza
your data center any day. Now this is no offense to your data center,
just as a programmer I can't see the need for it and won't support a
product that jumps through hoops like that.
Best of luck with your product, and I look forward to the competition
that doesn't use second party servers.
> data (seehttp://spanningsalesforce.com), and we consider each user's