People who would create great content and later stumble into a business model are not likely to do so on a premium .tv name…which means most of those domain names won’t have high quality content on them. Those that do may see thin profit margins because they have no control over their domain names…as they make them more valuable the registrar can increase prices without mercy, and when the registrant can no longer afford the domain names the registry gets to keep or sell any brand value the registrant built up. 

John Scott had a great post about people feeling guilty for buying links:

If you feel guilty about buying links, you’re probably feeling guilty for a reason. Perhaps your guilt comes from the fact that you are trying to rank a site for a keyword it doesn’t deserve ranking for. If that’s the case, stop trying to rank it for that keyword, and get you’re business in order. Get the site and your business to the place where you can honestly say that your site deserves to rank #1 for that keyword, and your business deserves to be #1 based on the merits of your business.

Yesterday at a market I bought this terrific soap with my girlfriend. The problem is that the packaging has a URL on it. No need to go to the vendor again. It is hard for the end vendor to get any traction as the supplier sells directly, has pricing control, and is more convenient to order from.

If you are too dependant on any one supplier or any one source of leads then you need to re-evaluate your position to decrease your risk profile and come up with ways to build your brand value.

Comments

Tag:

It started partly at Hack Day, Kremer and Yahoo Developer Network leader Chad Dickerson told WebProNews in a conversation ahead of the formal debut of the Yahoo Mail SOAP web service.

Attendees at that event got to see a preview of the API, leading to a nifty hack created by Leah Culver.

Details behind her hack, featuring Flickr, Greasemonkey, and Yahoo Mail have been posted as a video slideshow.

She built a Flickr Postcard, which takes the text entered in a form for the postcard, and finds an image on Flickr to match it. Then the postcard goes through the Yahoo Mail service to its recipient.

(If anyone’s curious about when the next Hack Day will be held at Yahoo, well, we don’t know either. We asked, and another one hasn’t been planned yet. Dickerson said a lot of people have been asking that question.)

Kremer clarified how developer usage of the API will differ between Yahoo Mail and Yahoo Mail Plus, the premium version of the email product.

Developers will be able to create mail preview utilities for the free version of Yahoo Mail.

Applications with richer features can be built for Yahoo Mail Plus users; those apps could be ones that list inbox contents, do scheduled email backups, or enable the user to create and send an email as in the Flickr example.

There’s a little something extra on the table for application developers.

Approved developers who refer new people to become premium Yahoo Mail Plus account holders will earn a commission of $10 per referral during a trial period.

Another slideshow available from Yahoo provides a walkthrough of the Yahoo Mail API. Ryan Kennedy, known for his role as Yahoo Mail evangelist, narrated the 12-minute presentation.

As with other Yahoo web services, developers can make their work part of Yahoo’s Application Gallery.

The broad reach of Yahoo’s mail service should encourage clever designers; a truly great mashup could end up attracting a lot of attention from that sizable email userbase.

The Bottomless Inbox

Yesterday came word of "unlimited" storage for all mailboxes on Yahoo mail. What can I say, storage is getting cheaper all the time.

SOAP and JSON-RPC APIs

Today’s news is that the Yahoo! Mail API that we previewed at last year’s Open Hack Day is now available to all developers. It speaks both SOAP and JSON-RPC and is well documented. The SOAP API is the same API that the mail front-end uses to talk to the mail back-end mail system, so it’s the real deal. There’s sample code too. And even apps it the gallery.

Screencasts!

In the last few weeks, Matt McAlister and I sat down to talk with a few folks using our "screencast interview" style. So I present two videos for you Quicktime viewing pleasure:

• Yahoo! Mail API Overview where Matt and I talk to Ryan Kennedy (Y! Mail API Evangelist) about the API
• Flickr Postcard where we talk to Leah Culver about her Open Hack Day hack that use the Mail API, Flickr, and Greasemonkey

We’ll have lower fidelity versions up on Yahoo! Tube Yahoo! Video before too long.

Make Money Fast

Oh, I should also mention that if you build the next killer application and convince people to use it and upgrade to the premium version of Yahoo! Mail, we’ll pay you $10 per user. The sky’s the limit on how cool your mail front-end can be. We’ll handle the infrastructure.

This stuff has been in the works for quite a while and a whole team of people has been putting tons of work into make sure it all works right–especially Ryan Kennedy.

See Also

• Introducing the Yahoo! Mail Web Service (Chad on the Yahoo! Developer Network blog)

Comments

If you opt into distribution of your product the way to win is to give extras when people buy direct. As a marketing strategy, it is silly to recommend people avoid your distribution partners. Once you give up distribution you move toward being a commodity unless you add extras or are selling a buying experience.

Even companies like Adobe are canibalizing portions of their business to maintain their market position. When considering opting into other networks or doing things that extend your reach and give you more direct control over the conumer experience it is probably best to stay as close to the consumer as possible.

If you are a product on the shelf you have to pay for shelf space. If you own the shelf space you can sell your own product or sell overpriced ads to others.

Comments

Transparency into Google might be better described as a frosted glass block that’s been licked by a dog on a cold morning. Consider the terse statement attached to the SOAP page at Google disclosing the change:

As of December 5, 2006, we are no longer issuing new API keys for the SOAP Search API. Developers with existing SOAP Search API keys will not be affected.

For developers who are already using the SOAP Search API, we’ve kept the documentation live on this site.

SOAP had been an API route to Google’s search results, but one that lacked a significant part of Google’s web-based search experience – paid search advertising. The Ajax API is quite different, as Brady Forrest noted on O’Reilly Radar:

The abrupt nature of SOAP’s retirement also surprised Danny Sullivan, now writing at his Search Engine Land blog.

“One of the main issues I have is that Google did this without warning or even a blog post saying, hey, we did this,” he said. Developers probably felt the same way, and one commenter suggested the move may have been made to foil efforts by one group in particular:

We talked to Mike Marshall at Fortune Interactive a few months back about their SEMLogic product. With that, Marshall claimed they could know how competitive a client’s pages would be in a search index before ever being crawled.

That sounds like the kind of product that would raise some Googly eyebrows. Instead of losing potential ad views, a low-percentage scenario given Google’s search dominance on the Internet, slamming the door on applications that may give webmasters too much of an edge in improving search placement would be more in line with Google’s emphasis on quality websites.

UPDATE!: A reader in the SEO industry alerted me to a solution to Google’s dropped SOAP, a SOAP gateway that allows applications that use the API to continue working. It works by translating SOAP calls into requests to Google’s web interface, scraping the results, then packaging the data back into SOAP. It’s called EvilAPI and the source code may be downloaded from the site.

Update 2!: Google’s Mark Lucovsky just posted a note about the SOAP API at the Google Code blog; his post just restates the original announcement, including the observation that “the AJAX Search API does not provide server-side access to search results,” which was the whole point of the criticism of the abrupt SOAP shutdown.

Update 3!: Mike Marshall from Fortune Interactive touched base to clarify a point about SEMLogic, which I’ve corrected in the text. He emphasized usage of SEMLogic is all about on-page and off-page quality; they have no use for short-term or short cut tactics to help a client rank well with the search engines.

—

Add to Del.icio.us | Digg | Reddit | Furl

Bookmark WebProNews:

David Utter is a staff writer for WebProNews covering technology and business.

That’s interesting because it’ll hurt Visual Studio developers (VS likes SOAP and WSDL, not AJAX).

Yet another defining moment. This is Google’s way of saying that “we don’t care about Windows applications anymore.”

Last week I posted a video with Lucovsky where he shows off some of the things that are possible with the AJAX Search API.

Lucovsky writes: “While the AJAX Search API does not provide server-side access to search results, it has a number of more powerful features, including access to Video, Maps, Blog Search, and News search results.”

What do you think? How will this hurt or help Microsoft and/or Google?

UPDATE: Dave Winer wants to string up the developer and/or team that came up with the just shipped Del.icio.us API.

UPDATE 2: Yesterday Dave Winer chimed in on the Google API deprecation. He thinks it leaves opportunities open for Google’s competitors.

UPDATE 3: David Cooley likes Google’s new API, says “they listen.”

Comments

Tag:

Add to Del.icio.us | Digg | Reddit | Furl

Bookmark WebProNews:

Robert Scoble is the founder of the Scobleizer blog. He works as PodTech.net’s Vice President of Media Development.

Go to Scobleizer …

That’s right; Google has vacated its SOAP API in favor of the new one, which was developed using the AJAX architecture.

Before those of you using the original API descend on Mountain View in a panicked state, be advised the SOAP API still works although Google will not be issuing any more keys for that particular API. From now on, users will be asked to download the AJAX version.

For those of you who are confused about the two development styles, Wikipedia has more. SOAP stands for Simple Object Access Protocol and in reference to Google’s API, the technology is primarily used to relay XML-based messages from the client to the server.

AJAX is defined as Asynchronous JavaScript and XML. The idea behind AJAX to reduce the amount of full-page loads associated with standard content updating. By using AJAX, the entire page doesn’t need to be reloaded – only the section being updated. A

great example of AJAX in action is the Google personalized homepage. The content modules are developed using AJAX.

Speaking of the AJAX version, does it perform like its SOAP predecessor does? In a word – no, it does not. SearchEngineRoundtable’s Barry Schwartz has more:

As of this writing, Google has not explained why they discontinued support of the SOAP API, so we are left with the speculation of others to figure it out. Most likely, the reason for the switch has to do with Google’s further embrace of the AJAX technology (personalized desktop is done in AJAX).

However, this is undoubtedly a small comfort for those who have been referred to the SOAP version. If the AJAX version was more robust, it’s doubtful there’d be any outcry… but when you change the technology and the functionality, there will be some unhappy users.

Aside: according to Barry’s post, Google is still issuing SOAP API keys. However, when I tried to apply for one using the link provided, I was taken to a Google 404 page.

When I tried to backtrack my way to the beginning of the sign-up process, I was taken back to the page where Google says they will no longer actively support SOAP.

Add to Del.icio.us | Digg | Reddit | Furl

Chris Richardson is a search engine writer and editor for WebProNews. Visit WebProNews for the latest search news.

Joshua is a Principal Software Engineer for Google, before that an architect in Sun’s Core Java Platform Group (he designed several of the standard java API’s). Josh also wrote Effective Java.

Here are a few points from the presentation that I found interesting…

• If you program, you are an API designer
• If you keep the spec short, it?s easy to modify
• API Should Do One Thing and Do it Well
• API Should Be As Small As Possible But No Smaller
• Names Matter – API is a Little Language
• Fail Fast – Report Errors as Soon as Possible After They Occur

Related Entries

Cheat Sheet Roundup – Over 30 Cheatsheets for developers – September 1, 2005

REST vs SOAP Web Services – August 3, 2005

Designing from the outside in – April 27, 2005

Google Code – March 17, 2005

*Originally published at Pete Freitag’s Homepage

Pete Freitag (http://www.petefreitag.com/) is a software engineer, and
web developer located in central new york. Pete specializes in the
HTTP protocol, web services, xml, java, and coldfusion. In 2003 Pete
published the ColdFusion MX Developers Cookbook with SAMs Publishing.

Pete owns a Firm called Foundeo (http://foundeo.com/) that specializes
in Web Consulting, and Products for Web Developers.

In this tutorial, I will be demonstrating how to use the SOAP package from PEAR to query Google’s extensive database. This tutorial assumes that you are using PHP 4 or higher and PEAR::SOAP 0.8.1, and requires basic familiarity with PHP (including a little object-oriented programming).

Note that both Google’s service and PEAR::SOAP are technically still in beta, so you might encounter the odd bug from time to time. There are other SOAP client libraries available, including the PHP5 SOAP extension and NuSOAP, and while implementation details are different the basic theory is the same as presented here.

Setting up the PEAR SOAP module

Before we can start using SOAP, we had better make sure both PEAR itself and the SOAP module are available. The PEAR package manager is installed by default with PHP 4.3.0 and later, but if you are using an earlier version or it is missing on your system check out the PEAR manual for instructions.

Once you have the package manager installed, you will need to download the SOAP package. On most systems, you can just enter pear install SOAP into a console window. At least, that’s the theory. Unless there is a stable release of SOAP available, you will get the message No release with state equal to: ‘stable’ found for ‘SOAP’. Try pear install SOAP-beta to get the most current version of the package at the time of writing, even though it is in beta, or tell PEAR to accept beta versions without complaint by typing pear config-set preferred_state beta.

You may also get one or more messages starting with requires package, followed by Dependencies failed. In this case, try the pear install command again but add the dependencies on the command line. For example, if PEAR complained that the Net_DIME package is missing, try using pear install Net_DIME SOAP instead.

Getting a license key

Once you have installed the SOAP module, the next step is to download the Google Web APIs developers’ kit and register to get a license key. This key allows you to make up to 1000 SOAP queries a day free of charge. Visit Google Web APIs (http://www.google.co.uk/apis/) and follow the instructions on the site.

Unzip the developers’ kit and put it in a convenient place. It only contains samples for accessing the service with .NET and Java, but most of the documentation applies equally to calling Google from PHP.

Decoding the WSDL file

In the developer’s kit main directory you will find a WSDL file called GoogleSearch.wsdl, which you can open in a text editor or XML browser. This file defines exactly what services we can call using SOAP, though the Google documentation is probably easier to read!

However, we can also see what the SOAP module makes of this file. Create a new PHP page and enter the following.

<?php

?>

Place it somewhere on your server along with GoogleSearch.wsdl and access it through your web browser. Assuming everything is working right, you should get a lot of PHP code output. This code is the result of the SOAP_WSDL client class parsing the WSDL file and converting it into PHP functions. This tells us what functions we can call in a rather more readable form than the WSDL document, and is handy particularly if you are using a poorly documented WSDL service.

So how does the code work? Let’s go through it step by step:

1. First, we load the SOAP client file. If this gives an error, it probably means SOAP isn’t installed properly and you should read the instructions above or the PEAR manual.

2. We then create an instance of the SOAP_WSDL class, based on the GoogleSearch.wsdl file. This is one of the main classes we are going to use throughout this tutorial: it parses the WSDL file and represents it as PHP.

3. Finally, we output the proxy code as plain text. (As you can see from the output, in SOAP the proxy is a class that represents the WSDL calls available as PHP functions.)

Spell-checking with Google

If you’ve been using Google for a while (and type as erratically as me), you have probably noticed the “Did you mean…” line that appears if you misspell a word in a search. Thanks to the Google web service, we can add this spelling checker to our PHP applications (though to be honest, it would probably be better to use pspell in an actual application). Enter the following code, with your own license key as the first string.

<?php

?>

Simple, isn’t it? The first line is trivial and the next two are the same as the previous example. The fourth line creates the proxy object based on the code we looked at earlier, so we can make SOAP requests by calling its methods. Finally, we call doSpellingSuggestion and output the result. Access this page in your web browser, and you should see the word ‘dictionary’ on its own.

You might see ‘Object’ instead, in which case SOAP has encountered a problem and returned a SOAP_Fault object. We will look into dealing with these faults sometime in the future, but for now check if you have entered your license key correctly and not managed to exhaust your 1000 query per day limit (!).

Tag:

Add to Del.icio.us | Digg | Yahoo! My Web | Furl

Bookmark WebProNews:

Joeri Cornelissens is the author of this article. For more information about the subject please visit http://www.phphacks.com/