Google I/O 2009 - Building Applications in the Cloud

Uploaded by GoogleDevelopers on 01.06.2009

Sabharwal: All right.
Good morning or good afternoon, everyone,
and welcome to "Building Applications in the Cloud."
Thank you very much for joining us.
My name is Anil Sabharwal.
I'm a Product Manager at Google
for the Documents List API.
Bidelman: And I'm Eric Bidelman.
I work as an engineer on the Documents List API.
Sabharwal: So over the next 45 minutes to an hour,
we have a pretty exciting session for you.
It's pretty jam packed.
We're going to try to have a nice balance
between looking at some really cool demonstrations,
as well as doing a bit of a deep dive
into some actual code samples,
so we'll give you the best of both worlds.
We're also excited today to have
a couple of partners with us.
We have Sandosh from gDocsBar
and Ondrej from Syncplicity,
couple of partners that use the Google Data APIs,
that'll be here to talk to you a little bit
about some of the applications they have
and some of the exciting releases
that they have coming.
You'll also note here just at the bottom,
we are using Google Moderator for this presentation.
For those of you who haven't used Moderator before,
you can just go to that link there,
and you can actually just sign in,
and you can put in a question there,
and people can vote,
and at the end of the session,
we'll have Q & A for about 10 to 15 minutes.
You're more than welcome to come up to the microphone
and ask the question live,
or, of course, we'll look at Moderator
and ask the question, or answer the questions
that appear on Moderator.
All right, so let's get started.
So let's do a quick poll.
How many people here have built an application
using one of the many Google Data APIs?
Great. Excellent.
And how many of you are familiar specifically
with the Google Documents List API?
Okay, great. Brilliant.
So the majority of you
have interacted with the Google Data APIs,
and a small group of you
have also seen the Documents List API.
Great. So today, basically, what we wanted to talk about
a little bit is where we've been and kind of where we're going,
and the opportunity around
Building Applications in the Cloud.
And I'll talk about that in a second.
But one of the things that I know Eric and I love
about Google, and many of you have probably noticed,
is the pace of innovation.
So if we look at this API as just an example,
the Google Documents List API.
A year ago, there wasn't truthfully a lot
that you could do.
We provided some basic use cases around being able to
download--sorry-- being able to actually retrieve
a list of documents.
We had a limited query model
that allowed you to be able to find out,
you know, find a document that matched a title,
or be able to look for a particular spreadsheet.
We allowed you to upload documents, presentations,
and spreadsheets,
and we had the ability to trash documents.
That was it. That was literally where we were
about 12 months ago.
Well, the good news is we've come a long way.
So in less than 12 months,
this is a small subset of the functionality
that we've made available through our API.
So we now do things like folder management.
We let you set account level permissions.
We have metadata that you can query over.
You have an export servlet, where you can download documents
in a variety of different formats,
so you can download your presentations
in Excel, for example, or in ODS.
We have an advanced query model
around who, what, when, where.
Really the ability to kind of manipulate the data
and get the information that you really want.
We have the ability for you to actually edit documents
right there in the cloud through the append service.
And we have a couple of new announcements
that we're going to make today
around extending functionality
around things like revision history and others,
which we'll get to.
We're not going to cover all of these today.
This is just kind of a subset again
of the type of functionality
that we've released in the last 12 months.
We wanted to give you an impression
of kind of the direction that we're going.
Now, today's session's around cloud applications,
and what we really wanted to talk about
is how organizations and how users
are building applications
that use the Google cloud service
as a platform.
As a file system in the cloud,
as a database in the cloud.
The ability for you to actually create
a Google document or a Google spreadsheet
and use that as your database
for building really interesting, rich applications.
And the ability to, as an enterprise,
be able to get access to that data,
manipulate that data,
and manage it in an intelligent and intuitive way.
So we talked to enterprises before doing this session,
and we came up with five particular use cases
that we wanted to talk about today.
The first is migration.
So how do I get my information into the cloud,
and then, of course,
how do I get it back out of the cloud?
And how do I handle different revisions
as different people are manipulating the same documents,
how do I make sure I'm getting the right access
to the right revision?
Sync--this is obviously a very important problem
that we need to be able to address
in terms of how do I make sure
that the information that I have locally
on my machines or in my local network servers
are up to date with the information
that I have living in the cloud?
Querying--so how do I get access to this information?
How do I find information
that meets a particular criteria?
Sharing--this is obviously the big Google Docs
kind of prime benefit
in terms of being able to take any piece of information
and share it and collaborate it and edit in real time.
So how do I take advantage of that?
How do I work with different people
within the organization?
How do I inter-operate across different applications?
And for any lawyers in the crowd,
legal discovery.
Basically, how do I manage situations
where, perhaps as an individual,
I can get access to my information,
but as an organization,
I need to be able to get access
to information for all of my users.
So if I'm being-- perhaps in a legal case
or I'm being sued by an organization,
I need to find all documents or spreadsheets
or presentations or PDF within my organization
that meet a certain criteria.
And this is a really interesting use case
of 2 Legged OAuth, which we're going to talk about,
which will really let you almost impersonate
the user to gather information and data.
So these are the five use cases
that we're going to talk about in detail today.
Again, nice balance across demonstrations
as well as some code samples.
But what I'd like to do is I'd actually like to kick off
with a couple of really cool partner demonstrations.
And the first one is from Sandosh,
who I'm going to invite to come up here to the stage
and give us a nice presentation on a tool that he's developed
called GDocsBar.
Vasudevan: Good afternoon, everyone.
Um, first I'd like to thank Anil and Eric for inviting me.
It's good to be here,
and I'd also like to thank Manu for collaborating
with me on this project.
So let's get to the demo.
The idea behind the tool was to shrink this UI
into a simple, and yet powerful interface
to kind of, you know, use Google Documents
in a better way.
So it's a form of a Firefox extension.
It's a sidebar.
There it is.
So you can actually perform most of the functions
that you do on
using this tool.
You could filter the documents
by various parameters-- own, open, start,
private, hidden.
You can also filter it by document types,
document presentations, spreadsheet, PDF.
And like Anil mentioned, the few use cases
that enterprise users required or asked for
was to migrate, how to get documents inside
and how to get documents outside.
So I'd like to demonstrate,
how do we get documents into Google Documents?
You could start writing a new document,
or, you know, you could do a new presentation
or a spreadsheet.
Let me go ahead and do a new document.
And you can also upload documents, say...
And they're immediately available here.
You can also drag and drop to the sidebar,
and it automatically uploads for you.
You could also do a search.
You could search documents by, let's say--test.
This will actually search for the contents of any documents.
Unfortunately, it's not found.
So, uh, you could also do a query by title.
You can do an exact...
Uh, no. Let's do it like...
There it is.
And how do we get documents out of
You could do an Export, say "Save As" RTF, Word, or PDF,
and also document type specified.
So if you go to Excel,
you could save it as PDF, CSV, or, you know,
Tab Separated Data.
And then you could start it,
or unstart it right from gDocsBar.
You could also browse folders, say...
And you can rename a document.
You could also do a move to, you know, folders.
And let's say you're working on some project
and you want to download that, you know, various documents
off the project in just one click,
you could do that.
You could do a search for documents
that are part of the project,
or you could go to Folders, do a Select All
and Download.
Um, that's it. That's a short demo of gDocsBar,
and thanks again.
[audience applauding]
Sabharwal: Great. Thank you, Sandosh.
The next partner demonstration that we're gonna do,
I'm gona invite Ondrej from Syncplicity
to please join me up here.
Sync is always something that our customers
are asking for us,
and I think Ondrej and the Syncplicity team
have a great solution,
and I encourage them to tell us about it today.
Hrebicek: Thank you, Anil. Sabharwal: Thanks, Ondrej.
Hrebicek: That was a great demo, Sandosh.
I've been using the gDocsBar for a couple of days now,
and it's working-- it's working great.
Hello, everyone. I'm Ondrej.
I work for Syncplicity, where I'm responsible for
product and API design and development.
Syncplicity is a start-up based here in San Francisco,
looking for ways to make it incredibly easy
for people to share and access their data.
The basic premise behind Syncplicity
is that our folders and files should always be accessible
to us and to those we share those files and folders with
without even having to think about it.
And what we have done at Syncplicity
is built a file synchronization platform
that's exposed as a web service
and works together with our lightweight desktop application
to keep your and your coworkers computers
in sync.
Um, however, we've also realized that it's no longer enough
to just have the latest copies of your documents and photos
instantly synchronized to every computer.
After all, that's not where
you always need those documents anymore.
These days its web applications like Google Docs
that we've come to increasingly rely on
and where we need our data just as much,
if not more.
Currently, Syncplicity synchronizes
hundreds of thousands of documents
between our users' desktops
and their Google Docs accounts.
Some use us for two-way backup.
Some use us to take the opportunity
to explore the online world of Google Docs.
But perhaps most interestingly,
many use us to help bridge the divide
between the Microsoft Word devotees
and the Google Docs enthusiasts
by letting both camps use the tool they prefer the most.
With Syncplicity, companies no longer need to choose
between one or the other.
They can have both,
and they can have Syncplicity take care
of all the complexities on the back end.
Complexities like revision control,
conflict resolution,
and multi-machine synchronization.
So imagine Rachel, a marketing manager
who works for Syncplicity and works on documents--
on documents that we publish to our website
and documents that we publish together with our service.
Rachel knows Microsoft Word very well
and enjoys working with it.
At the same time, however,
she needs to share her documents with other people.
In this case, she needs to share those documents
with Isaac, our CTO, and a long-time Google Docs user.
Isaac uses Google Docs exclusively,
and he'd love to see all of the documents
he needs to interact with right there in one place.
So here's what they would do.
So I'll pretend to be Rachel for a few minutes.
Um, Rachel keeps all of her documents
right here on her desktop in a folder called Marketing.
The folder is under Syncplicity's control,
and there are two documents in it.
Rachel also recently created a Google Docs account...
that has a few stock documents inside of it.
In order to keep the Marketing folder
and her Google Docs account in sync,
Rachel needs to link her Syncplicity accounts
to her Google Docs account.
So let's do that right now.
So Rachel will log in to Syncplicity.
She'll click on the Applications tab...
and she'll associate her Google Docs account
with her Syncplicity account.
She'll grant access to Syncplicity
to her Google Docs account, and she'll pick the folder
that she wants to synchronize
between her computer and her Google Docs account.
In this case, it is the Marketing folder
that I had mentioned previously.
At this point, Syncplicity has recognized the link
between her Syncplicity account and Google Docs
and begun synchronizing the two together.
What this means is that all of the documents
that she has in Google Docs will sync right down to her PC,
and all the documents on her PC
will sync right back to Google Docs.
Perhaps most importantly,
those two places will now be kept in sync
always and all the time.
Any changes she makes in either place
will be immediately reflected on the other side.
When Syncplicity's all done, it lets the user know,
in this case displayed a little balloon pop-up at the bottom,
and the two stock documents that we saw on Google Docs
have magically appeared right on her computer.
Here they are.
Let's now go back to her Google Docs account
and refresh,
and the two documents that she had on her PC
are now in her Google Docs account,
and you can see that they were uploaded right about now.
The document that she'd like to share with Isaac,
and get feedback from on,
is called Syncplicity FAQ.
So let's go ahead and share the document
with Isaac.
Okay, let's log out of Rachel's account
and log back into Isaac's account.
And, hopefully, the document that Rachel shared with him
is right here. Let's go ahead and open it.
And there it is.
You can see that there's actually a typo in the document.
No problem. We can correct that.
So I'm going to close the document,
and now, being Rachel, I'm going to go back to my PC,
where I'm spending most of my time on,
and open the Syncplicity FAQ document in Word.
Give Word a few minutes to load up.
It's connecting to the printer.
[audience laughing]
And here it is.
So I'm going to go ahead and make the change.
I'll change "kwestions" to "questions."
As soon as Office lets me in.
What Syncplicity's going to do as soon as I make the change
and hit Save is synchronize the document
right back to Rachel's Syncplicity account.
Um, as soon as it gets there,
it's going to be versioned and backed up.
Um, a few moments later,
it will then be synced right back to Google Docs.
Um...and if Office... if Office let me in--
There we go.
I think I can finally... can finally edit it.
Slowly, but surely.
Um, and I save the document and I close it.
At this point, like I had mentioned before,
the document is being synced to the cloud,
first through Syncplicity and then right to Google Docs.
So let's go back to Google Docs,
um, and Isaac's account again.
I'll refresh and open the document.
Again, you can see that the document
is now correctly spelled and everything looks great.
Um, so that's what Syncplicity does.
This is one of the many things that we do.
Our website is at
Take a look at us.
The whole Syncplicity team
will be available after the talk
in case you have any questions.
Um, and that's it for me.
Thanks so much.
[audience applauding]
Bidelman: All right. Hey, everybody.
So let's dive into some code.
So the protocol-- I think a number of you
have probably used-- We have 14 or 15, 16
Google Data APIs at this point.
The Analytics API and the Maps Data API
are some of the newer ones that we just launched,
um, you know, within the month.
But the protocol itself is fairly straightforward.
We're just going to cover the basics as a crash course.
For those that are familiar, this will be quick.
For those that aren't,
you're going to get a lot of information here.
So it's HTTP, it's a REST base,
the full CRUD model.
You can read data, you can also write data.
Um, it extends the Atom publishing protocol,
so it's just Atom XML, these are common protocols.
If you're familiar with them you know,
you can pick up one of these APIs
and then use the same code, same similar code
across multiple APIs.
And so what we do a little differently
is we extend the protocol by having authentication,
so that's important 'cause you don't have to roll your own.
You can use AuthSub, you can use client log-in,
or OAuth, which is an open standard
for authorizing access to the web,
We extend the data model.
Here's my nifty laser pointer.
It doesn't work.
You can't see it.
Extended data model, so "lastModifiedBy"
in the case of Google Docs, you can see who's modified
and when they modified the document.
We do batch operations
so you can wrap up, you know, a bunch of requests
into one single feed,
and then the server will process that
and send back a response for you
so you can save some overhead there.
And then lastly, you can request responses
from the server in different formats,
so you don't have to use Atom XML
if you're not comfortable with it.
I certainly don't like XML myself.
So you can do JSON or JSON-IN-SCRIPT
and provide a callback function
if you're in a JavaScript environment.
And so that image, I think, you know,
pretty much explains it all.
You know, we have the cloud,
we have the APIs, we can make mashups.
We can do Contacts, Calendar, Docs.
We can do a multimedia app like Picasa and YouTube.
So the possibilities are really endless.
So under the hood, what does it sort of look like?
Um, you know, we're just making get, puts, deletes,
requests to the server.
In this case, we're requesting a user's list of documents.
This is an authenticated request.
You see that authorization header there.
It's got a Auth/Sub token.
We saw that sort of process in the Syncplicity demo.
So what you get back, you get a 200 OK,
and you get a bunch of XML.
At its rawest form, you know, you have a feed
and then you have a bunch of entries,
each entry being a document.
And there's a bunch of metadata there.
We'll take a look at that in a sec.
So if you don't want to use XML, if you don't want to use,
you know, HTTP, you don't have to.
I wouldn't choose to do that.
So we do offer a number of client libraries,
and there's sample applications available
so you can get up and running very quickly.
And they just provide a higher level API.
They handle some of the complexities
of the token management and making the raw calls,
and there's a lot of great helper functions there.
There's also a JavaScript client library
that's not up there,
and that's both a read and write client that you can...
It uses it's own cross-domain communication.
So the first, um...
First enterprise scenario that Anil mentioned was migration.
And so this is an important one.
You're gonna want to sync
your local client to the cloud, right?
And then you want to be able to get those documents back out,
those files back out.
And so the Documents List API, as Anil mentioned,
provides document creation.
You saw that also in the gDocsBar demo.
You can create documents.
You can create folders,
so you can preserve the folder hierarchy,
between the two clients,
between the online version and the offline version.
So just a simple example here.
We're making a post request to that same documents list URL.
You know, it's authorized.
We'll probably need an AuthSub token there,
and then we're just creating a simple Atom entry
and creating a category that's a folder,
of a type folder,
and then calling it Example folder.
So if all goes well, that folder should be created
within our documents list.
Uploading content is a little more involved, right?
'Cause you're creating a document the same time
you're actually putting content into the document,
so this is a MIME multipart request.
So it's the same process as before.
You know, it's an authenticated call.
Same feed: URI.
But instead of just creating that example document,
we're actually appending Microsoft Word content there.
And instead of using the folder category,
we're using a document category.
So fairly straightforward, same process.
Again, the client libraries handle all this for you,
so I encourage you to check them out.
I'm actually gonna skip this demo
in the interest of time.
We have a lot to cover.
But you saw some of this export functionality
in the gDocsBar sample.
This is actually contributed by a third-party developer
on one of our forums.
It's open source.
It uses our .net client library.
Do check it out.
And basically what it does, it just allows you
to back up your entire Google Docs
to your local machine,
and you can specify what type of export format
you choose for each different type,
whether it's document, presentation, spreadsheet.
So, how is that done?
We have an export servlet that's relatively new,
so you can always, you know, your files up in the cloud,
but you can never really get them out,
unless you're viewing them in Google Docs
or exporting them manually.
So now you can do that programmatically.
And so the documents and presentations,
each have their own export servlet,
and then the spreadsheets also has its own.
And all you really do is reference the type of document
and the I.D. of the document
and the format you want to export in.
And as you can see there,
we have a number of different formats,
ranging from the open office formats
to the Microsoft formats
and ZIP, TXT, what have you.
So sync. Sync is a hard one.
Um, Syncplicity's done a great job.
You saw some of that,
and maybe you can ask them how they did it after this.
But you can imagine setting up some kind of cron job
or whatnot to back up your local machine every night.
Um, and just as simple example, using Python client library,
you know, that five lines of code,
not including that import statement there.
So we're setting up a doc service.
With any of the client libraries,
you're going to typically set up a service object,
you're gonna pass it,
you know, your application's name.
You're going to do some kind of authentication if needed.
In this case, your documents are all private,
so you're going to need to authenticate.
And then you just reference amedia source--
maybe it's an Apache log
that you're uploading to your Google Docs every night--
the content type,
and just call one of the helper functions Upload Document.
So it's literally that easy,
in, you know, five or six lines of code here
to back up all your docs.
And in this case, we're just printing
the document that was uploaded, its title,
and then the alternate link,
which is the link to Google Docs,
so you can open that up in a web browser.
So we have a more advanced query model
than we used to.
Um, you know, we support the Google Data standard proto--
Excuse me, the Google Data standard query model,
which is q for full-text search,
you can search by title, by author,
by the updated time stamps,
and start-indexes used for pagination.
But we also have some other stuff
that's, you know, specific to Google Docs.
Here's a few examples. I hope you can see them.
The first one, you know, let me just query
all my documents updated within this minimum time frame,
and then order them by title,
so you can do some kind of syncing that way.
Query the documents, maybe store them locally,
and then make modifications,
re-upload them to the cloud.
You know, you can use category, um...
I'm sorry. I guess you can sort of see this now.
So you can use category queries.
Give me all my documents or spreadsheets,
and also documents or spreadsheets
the user has not viewed,
so you can see that maybe you upload an HR packet
to your users using 2 Legged OAuth,
as we'll see in a second,
and see if they've actually viewed the thing.
So give me all my PDFs that I own,
and they're also shared with the domain.
So if you're in a Google Apps domain,
you can do some special queries there.
You can query on folders, you can query on writers.
You know, "Give me the results in JSON,"
so you don't have to use XML.
So you can do a bunch of different stuff.
Once your data is in Google Docs,
you can use the API to pretty much,
you know, get it out anytime you want.
So at its basic level, here's what you get.
You get a list of entries in a feed
and with a bunch of metadata for each type of document.
So let's take a closer look at that.
So we have special categories, right?
We talked about that "viewed" category.
So this particular document has been viewed by the user,
because there's a "viewed" category.
We know what type it is. It's a document.
There's a document category there.
We know if it's in a folder or not.
In this case it's in a folder named ChildFolder.
We have the common set of Google Data links.
The "alternate" link is the one that we mentioned
that points to Google Docs.
You can open that up in a web browser.
We have the "self" link
that references this particular entry.
And then we have the "edit" links,
which you can use to actually modify the content,
so the "edit" link being the one you use to modify it.
Metadata, such as the title--
Excuse me. "Edit-media" is the one
you use to update content.
Lastly, we have sort of a section of special attributes
for the Google Docs API.
We have a particular resource I.D.
You can use that for the export servlet that we talked about.
You know who's modified the last document,
when it was last viewed, these two here.
And there's another one here, "writersCanInvite,"
so you can--This is analogous to the Google Docs, um...
When you share a document as a collaborator,
you can prevent them from sharing it
with further collaborators,
and so you can prevent that actually using API now
by setting this to "true" or "false."
This last one here is the feedLink
to the ACL feed, and we'll talk about sharing in a bit.
Before that, we're gonna see a really cool demo.
So the DocList Manager
was intended as a sample application.
It's written in Ruby on Rails
You know, it provides all the Rails/AJAX goodness.
Um, and it uses a colleague's utility library.
It's all open source. Those two are URLs there.
And it demonstrates some of the things we talked about
and we saw in gDocsBar and Syncplicity.
We have category queries.
We can use the export feed.
It's also a mashup between calendar--
Excuse me, contacts and spreadsheets and documents.
So let's pop over there.
Before I do that, I just want to...
If you haven't seen Google Code Samples,
I highly recommend it.
It's got all of our library samples
and all the sources on the side there.
You can run these. These are all live samples.
So do check it out,
and the DocList Manager is indeed there.
So the first thing you do is authorize this website.
And we'll do that using AuthSub
in the same fashion you saw in the previous demo.
The user chooses which account.
Looks like I've been logged out.
So the user's presented with the list of scopes,
the list of APIs that we'll be accessing,
so we know exactly what this application's going to do.
We'll grant access, 'cause I do trust it.
So we come back to the page,
and you see I just did an immediate query
for, you know, my list of documents that I own,
so I have just two, unfortunately.
But we can do the same for spreadsheets.
You know, we can drill down in folders,
seeing the folder structure of our documents list.
And so this server shows you
that you can use the API, uh...
you know, it's very verbose,
so you can literally rewrite the Google Docs UI if you want.
And so just click on one of these, you know,
I'm presenting that metadata we just took a look at.
The doc I.D., the title,
you know, "last updated" and whatnot.
Um, this preview image here
is actually just using the export feed.
We're just exporting as a PNG file
and just presenting that to the user.
You can also choose to export this document.
It's not as interesting as a TXT file,
but you can see it did work.
Here's the alternate link
that'll take us to Google Docs if I choose.
I did mention this is a mashup with context,
so it's getting a little cramped there,
but what I did here is I just queried the user's,
the sharing permissions for this particular document,
so I can actually add user one here as a writer.
So he's there.
So just a great example.
I think this took me probably, you know, a week or something.
Um, not very much time at all,
and using the API's functionality,
you really can accomplish a lot.
So we talked about-- Anil mentioned that we'd focus
mainly on the Documents List API,
but, you know, we wouldn't be
building applications in the cloud
if we didn't see some other ones.
In the Contacts API, we just saw spreadsheets and whatnot.
Um, so Spreadsheets, actually today,
they have office hours from 2:00 to 3:00.
I highly recommend going. They're gonna--
They're actually rolling out some new APIs today
that you can check out and learn from them.
It's gonna make it more...
If anybody is familiar with the Spreadsheets API,
it's going to make more feel like SQL.
It's got a better query model.
And of course you can use the Spreadsheets Gadgets API
for those that are familiar,
you can visualize your data within spreadsheets,
creating a gadget, which is really cool.
Um, so check that out 2:00 to 3:00 today,
in the Google Data office hours.
The fourth use case was sharing in ACLs.
This is the big selling point of Google Docs, right?
You can collaborate in the cloud.
You saw in the last sample that you can...
you can add users using the API.
So let's explain sort of how that's done.
There's that feedLink, which is on every document.
It's the list of sharing permissions,
and if you just query that,
what you'll get is a list of the different users
that have been added to that document.
So what you can do, you can add--
same thing you can do in Google Docs, right?
You can add owners, you can add writers,
collaborators as they're called,
uh, readers.
If you're on a Google Apps domain,
you can add everyone to that domain.
You can share that document across the domain.
There's batch support supported in this,
so if you're adding 25 users, you know,
from a Google IO event that you just met
and you want to share this document,
you don't have to do that one by one.
You can save yourself
a little bit of bandwidth there.
And lastly there's that "writersCanInvite" flag
that you can set, so that you can prevent
even further sharing of that document.
Maybe you don't want the collaborator--
You know, you want the collaborator
to edit the document, but not necessarily share that
with someone else.
And just as a tip,
you can actually, instead of querying
the documents list feed,
you can use a different projection,
which is expand ACL, and now actually inline
the ACL feed with inside of the documents list,
so you get all of that information
that we looked at in the documents list feed,
but you also get the ACL information as well.
So that'll save you a little overhead.
It might be information overkill,
but just a tip.
So at the very bare bones level here,
this is what it looks like. It's just another Atom entry,
if we're doing a get to that ACL feed.
The two important ones here are the ACL:roll, right?
And the ACL:scope.
So you know what type it is,
so it's a user in this case,,
and he's been set, or she has been set
to be a reader on this document.
Of course, a writer would be a writer
and an owner would be an owner.
And so you can imagine using this,
you know, looping through these different ACL entries
for some kind of discovery,
so you can discover documents
that maybe have been shared outside
of your Google Apps domain.
Maybe they've been shared with
So you can quickly find documents
that you don't want shared outside of your company.
I'm going to turn it back over to Anil.
He's going to talk about 2 Legged OAuth
and discovery.
Sabharwal: Great. Thanks, sir.
So one of the great things that you get
with the gData APIs for free is 2 Legged OAuth,
and basically this allows you to, as I described earlier,
effectively impersonate the user.
So imagine a scenario in your organization
where you have, um... you have a legal case
where the organization is going to court
over a situation where you now need to go and find out
who within your organization has ever talked
about the company ABC.
Now, you can get every single one of your users
to go through and do a query
and find the information, then pass it to you,
or, with 2 Legged OAuth, you can actually go in
as the enterprise admin with the consumer secret key
and be able to actually go through
every one of those things just as an administrator.
And it requires no user intervention.
It doesn't require the users to actually give that permission.
It allows you just to go in there and get that information.
And there's a number of different things
that you can do with it, as we described.
You can do it to modify the actual user permissions
across documents.
If someone has gone ahead and shared a document
that's confidential outside the domain
and you need to pull that back,
you have the ability to go in there
and be able to change those permissions,
be able to see who's looked at a particular document,
be able to actually add and update company contacts,
set calendar reminders, upload documents
into different people's accounts for induction.
There's a number of use cases where 2 Legged OAuth
comes into play.
One of the ones that we often get asked about
on the enterprise side has to do with legal discovery.
And as an example, we built a AppEngine application here,
where very quickly and simply,
using the Google Documents List API,
you actually have the ability
to pull up an advanced query model,
where you can come in and you can type in
a series of criteria that you want to refine
your search based on, including things like
exact title search or containing the words,
how it's being shared, whether it's private,
where it's shared outside the domain,
who it's shared with,
who the collaborators are,
the dates associated with that query,
and then, of course, who particularly owns that query,
so you'll see, I'll run this query here.
This is just off a sample domain that we've created
for the purposes of this demonstration.
And what that's going to do is it's actually going to through,
and it's going to look at this individual,
this custodian,,
and it's going to go in and try to find
all documents that meet that person's criteria.
Sorry. I don't think I pressed that button.
Um, and what will happen is it will actually appear
here with the information saying that I've requested it.
Here's the information,
here's the documents that are returned.
If I show the query of the detail--
Uh, the details of the query-- I'm sorry--
you can see that I can enter in some information here.
It returned seven documents.
Here's another query I ran earlier,
where I actually looked for the query,
for the keyword "awesome,"
and it returned one document,
and it actually returned me a Zip file,
which I can just open up,
and you can see what it's done is it's actually exported
all these documents into a Zip file.
Um, this is something that we plan to release
within the API very shortly,
the ability to export a Zip,
so you can get a number of different files,
zip them up and return them all in a single query.
So that will come out shortly.
And you can see that basically it just pulls up
all of the associated documents
that met that query requirement.
So just a really quick way to use 2 Legged OAuth
to actually go in and impersonate
any number of users.
And just to kind of look at how that was done,
the Java-- This was done using AppEngine
and the Java client specifically,
and you can see it's literally ten lines of code.
I mean, effectively, we go in
and extentiate a class of the OAuth,
we set the domain, we set the secret key,
we put in the information across,
who the user is that we're looking to actually impersonate,
and we run a request,
and you'll see this particular request is quite simple.
It just goes off and gets the feed of all the documents
for this particular user
and goes in and does a PrintLine across all of the titles.
But it's another very simple way of using 2 Legged OAuth
to be able to go in and get information,
so that export-to-Zip functionality
will be coming out soon
as well as information around revision histories
that we talked about a little bit earlier.
Now, um, we talked about a lot of things today,
and I want to end with a really quick demonstration
before we jump into questions.
There are a number of enterprise use cases
that we looked at in terms of being able to use
the Document List API, the Spreadsheets API,
the Contacts API,
using them together to be able to use it
as a platform for building cloud applications.
And one example of that that's kind of interesting
and exciting is this company by the name of OffiSync.
And, effectively, what they've done is
to help with the interoperability side of things,
is built an application that actually loads directly
within Microsoft Office
and allows you to interoperate with the cloud.
So just as a quick example here,
I can pull up PowerPoint,
and you'll see here that I have this ribbon.
So I have, you know, have
my normal Office 2007 information,
but I've got this ribbon here at the top for OffiSync.
And what I can do is I can click this Open button
and it'll pull up my cloud information.
So this going directly into my Google Docs account
to be able to pull in that information.
I can search by presentations, documents, spreadsheets.
I can do queries of information to be able to find things
that match a particular type of document
that I'm looking for,
and what this is actually going to do now
as I open this document,
is it's gonna go out to the Google Docs cloud,
it's gonna grab that document,
it's gonna convert it,
and it's gonna bring it down locally on my machine,
and now I'm living right here in PowerPoint
with a Google document.
I can hit the Save button.
I can make changes. I can hit Save.
It's going to go right back up into the cloud,
and now for those people within the organization
that are using Google Docs,
they have the ability to get access to it
directly within the Docs interface.
We talked about Search,
and the other one that I just wanted to quickly show
is that I can collaborate on this,
so I can really quickly say, here's a document.
Even though I'm in PowerPoint,
I can say that I want to share this, you know, to me...
whether or not I want to give myself Read or Write access.
Can hit Save. Apparently I don't exist.
Bidelman: Everyone just walked out of here.
Sabharwal: That's right. Oh, yes, thank you.
Get rid of that. We'll hit Save.
And we will skip the sending of the e-mail.
And, basically, what that's gonna do
is it'll go up to the cloud,
it'll change that document collaboration information,
and it'll provide me with Share access
and Write access.
So it's just a nice, 'nother example of ways
in which you can actually use the API
to interoperate across applications.
So here, someone using Microsoft Office
can really easily and really quickly interoperate
with someone using Google Docs
all within their own native applications.
So we've talked about quite a few things today.
And I guess the most important message here is...
Now, probably the big question is,
all right, great, where do I get resources?
Where do I get information to be able to learn more?
Bidelman: I'm glad you asked that question, Anil.
[Anil laughs]
So, as always, we have a list of,
you know, a bunch of resources.
There's the Documents List API documentation there.
There's information on 2 Legged OAuth,
if you're a Google Apps Premier or EDU user.
We have code samples,
you know, just numerous code samples
in different languages to get you started,
and there's a developer forum if you do get stuck,
so do ask around in there.
So I think for anyone that asked questions
in Google Moderator, there's a link,
if you want to ask some last-minute questions.
Also, feel free to come to mic so we can hear you on camera.
Sabharwal: We have partners here as well,
so if you have questions for gDocsBar
or for Syncplicity, please go ahead.
We'll bring up the Moderator.
We know it's lunchtime, so thank you for coming
to our presentation.
[audience applauding]
Now it's so lonely.
Sabharwal: Any questions?
Bidelman: We'll also be available up here
if you want to just ask us directly.
man: I had a quick question. Sabharwal: Please.
For the Syncplicity guy. What, uh...
Bidelman: Do you want to come up?
man: How does your tool handle images or HTML pages?
Hrebicek: Images embedded in documents
will sync together with the document.
man: I'm just talking about like straight pictures
thrown into the Sync folder.
Hrebicek: I see. They will not sync to Google Docs.
Not today.
man: But will they sync to other users
that have the Syncplicity software?
Hrebicek: That's exactly right.
So the Syncplicity syncs across all your computers,
the computers of the people you're sharing with,
as well as Google Docs and Facebook, for example.
man: All right. Thank you.
Hrebicek: Thanks.
Bidelman: Ondrej, do you want to come up on stage
just in case? You, too, Sandosh?
Sabharwal: Hi.
man: Great session, by the way. Bidelman: Thank you.
man: Um, is it possible to, um...
to use the, let's say the Google Spreadsheet
or Google Docs--Let's say, for example, Spreadsheet,
in such a way that we...
from within our application launch the spreadsheet,
have the user edit it,
and then suck the data back in from the spreadsheet
as the user hits Save?
How would we go about doing that?
Bidelman: I can answer that.
So, right now, the only way you can
actually upload content using the API
is, it's a wholesale, like, upload.
So it's either-- It's not little chunks.
It's the whole document, so what you would do
is you'd probably export the document,
if I have the question straight,
you would export the document in question,
you know, you'd make a local change or something,
and then just re-upload the whole thing to the cloud.
So the syncing there is not great unfortunately,
but that's something that's highly requested
from our users.
man: I'm sorry. I probably didn't make it clear.
So the question was that they allow the user
to edit or create a spreadsheet
within the Google Docs and just extract the data
out of those tables and rows into the system,
into a different third-party system altogether.
Bidelman: So that would be-- So the Google Docs API
is used to create and manage your documents,
including spreadsheets,
but if you want to actually get that content
in the spreadsheets, you use the Spreadsheets API.
[man speaking indistinctly]
Bidelman: Yeah, definitely go to their session at 2:00.
They'll have all the answers for you.
man: You had a demo of an application.
You said it took you about a week to put it together.
It was kind of an interesting thing.
I guess what struck me was, or what I was curious about
was how far up the learning curve
of the actual API were you at that point?
Were you already such a super expert
that one week for you is a year and one week for me?
[all laughing]
Bidelman: This is the Ruby on Rails one?
man: I forget exactly which it was.
Bidelman: So I think the thing that took me the longest there
was obviously the CSS and Ajax goodness, right?
Just to make it look all fancy and pretty.
Um, but, having said that,
you know, we do have the client libraries,
and we have, you know, great-- pretty great documentation
on how to do, you know,
just about everything in the APIs,
so you should be able to get up and running fairly quickly.
You know, we talked a little bit about the protocol
and sort of the underlying, you know, what's going on,
but you really don't need to look at any of that
if you're not interested in it.
I would say, you know, a great place is
to start off from the documentation link,
and you could have a full-fledged app going
in a week definitely.
You don't have to be a guru at all.
man: Now, one question,
you guys mentioned revision earlier.
What about deleted documents in OAuth?
You know, our legal team's constantly asking,
"Hey, this guy deleted this document.
"It had this sensitive information in it,
how do I retrieve it?"
So do tools like Postini,
are you guys going to extend that
to where we can access that information
through OAuth and things like that?
Bidelman: So to answer your first question,
deleting docs is absolutely possible today.
We just didn't cover it.
Um, you know, you can create, update, and delete docs,
using 2 Legged OAuth, so you can...
If, say, a user creates a document,
or, you know, I don't know, shares it outside the domain,
you just want to nuke that, you absolutely can.
Sabharwal: Yeah, and then on the Postini side,
I mean, certainly the vision around Postini
is to be able to provide that archiving
and be able to have litigation holds
and give the visibility and flexibility for enterprises
to be able to protect that data.
So, yeah, certainly our goal as an organization
is to find ways to be able to extrapolate that
across docs, across sites, across e-mail, and so forth.
man: Now, I heard of a couple of third-party guys
that had, you know, written apps against all that.
They've kind of mirrored the functionality with Postini.
Sabharwal: Mm-hmm.
man: Are you guys gonna, you know, on the road map,
do you guys know about when you're thinking
about integrating that just into the Enterprise,
all the clients?
Sabharwal: It's...
It's difficult to say from a road map perspective
whether or not that's gonna happen
through an integration with third-party partners,
whether that's something that we're going to develop
ourselves or work with enterprises,
but, you know, definitely,
it's something that's on our radars,
something that we need to resolve,
and we'll have a solution to market as soon as we can get
kind of the best possible thing together.
man: Thank you.
Bidelman: Want to do the Moderator?
Sabharwal: Yeah, we'll do the Moderator question.
So this probably why everyone is sticking around.
"Is Google going to release a 'G drive,'
and is this API going to support it?"
Um, so the short answer is that, um...
I can't say.
The longer answer is, at the end of the day,
Google's mission is to organize the world's information, right?
To make it universally accessible.
We recognize that that information
is beyond documents, spreadsheets, presentations,
so certainly, you know, we're working
towards finding ways to make it easy
for organizations to be able to share files
of all types, pictures, videos, documents, spreadsheets,
Zip files, et cetera.
What form that's going to come in,
all we're gonna have to do is be able to say stay tuned,
but certainly, definitely the information--
Sorry, definitely the vision and the road map
and the plan for Google is to be able to provide
enterprises and consumers with a way
to be able to share and sync that information.
I think that's it for questions,
so thank you all again very much for joining us today.
Please enjoy the lunch.
Bidelman: There's office hours later today,
so do check it out if you're interested.