[mashup-dev] Re: Summary on Google Developer Day - Gadgets

[E. Michael Maximilien]

> of adwords is primarily with enterprise customers. In Googles mind if
> the target audience is a non-enterprise community they use a RESTish
> API (more like the Atom based API in gdata). They tend to put the SOAP
> interfaces only on the services that they want to expose to the more
> enterprisy customers.

Jeff is being nice here...

See this blog post from Nelson Minar (ex-Googler  and the creator of  
Google's SOAP search API)

http://www.somebits.com/weblog/tech/bad/whySoapSucks.html

He has others on the subject as well.

I think the issue is deeper and rooted in having simple programming  
models for simple things (IMO) which should be kept simple, i.e.,  
less lines of code, maintainable, easy integration, and dare I say  
'beautiful'.

Of course the blogosphere is full of opinions of SOAP vs REST,  
including your own, but it's interesting that the market is deciding  
and the key factor is simple, simplicity of simple things vs. full  
featured capabilities or hard things...

Oh, can I use simple one more time!  Yes, I feel better now :-)

max

On Jun 1, 2007, at 9:51 AM, Ajith Ranabahu wrote:

> Hi,
> Here is the summary on Google gadgets sessions which I omitted from
> the last mail
>
>
> Google gadgets is a way of producing small widgets that either run as
> part of a web page or a part of the local desktop. Gadgets do provide
> nice and fun ways of delivering content and most people find it
> reallly cool since they can add an remove gadgets very easily (as the
> google guys put it - its 'extreme focus on user experience'). Google
> seems to have mastered this and here is a summary of the things I've
> learnet in the gadgets sessions.
>
> 1. Gadgets are of two types, universal gadgets and desktop gadgets.
> while the universal gadgets are more like html content with an xml
> wrapper, desktop gadgets run using google desktop runtime and are more
> powetful in terms of their ability to use the Google desktop and
> google talk API's to work with the local machine. Google destop API
> primarily includes a communication API, events API and a query API.
> The universal gadgets however can be used in both the desktop and your
> igoogle home page but their functionality in the desktop environment
> will not be more sophisticated than its web page equivalent.
>
> 2. Google desktop gadget designer is a tool that makes gadget creation
> fast and simple.
>
> 3. Communication API works on the gtalk framework! This is a cool idea
> and they've done cool things with it. One possibility is mutiuser
> games. Underneath it boils down to just passing text using the XMPP
> protocol, but creative people has used this API to many interesting
> uses. If the XMPP transport in Axis2 is upto the job, we can device a
> way of delivering web service content through gadgets :) Other API's
> rely on the google desktop support  - say to access the index created
> by google deektop program.
>
> 4. The desktop gadgets do seem have certain security risks since once
> the gadget is installed it can access the content of the local file
> system etc without restrictions.
>
> The mashup editor allows you to directly export a universal gadget out
> of your mashup. So instead of making a web site out of it, you can
> actually send it to user desktops instead.
>
> On a somewhat unrelated note I've had a chat with Jeff Huber, Googles
> director for Engineering (He is such a cool and humble guy) and he
> mentioned that they decided to drop the SOAP interface for search
> because they saw the world going the other way. Right now Google has
> only one SOAP interface, the Adwords API. The reason is that the use
> of adwords is primarily with enterprise customers. In Googles mind if
> the target audience is a non-enterprise community they use a RESTish
> API (more like the Atom based API in gdata). They tend to put the SOAP
> interfaces only on the services that they want to expose to the more
> enterprisy customers.
>
> Thanks
>
> -- 
> Ajith Ranabahu