Re: bit.ly urls

On 23/07/11 8:36 AM, Kent Crispin wrote:
> On Sat, July 23, 2011 06:23, JC Dill wrote:
>> On 22/07/11 11:35 PM, Kent Crispin wrote:
>>> No incentive whatsoever for a registrar to do this.  A registrar only
>>> registers
>>> domains in some TLDs, not all TLDs.
>> That's like saying there's no incentive to provide search results for
>> sites that aren't within your domain or where you don't place ads.
> Some additional detail:
>
> The incentives that apply to google are not particularly compelling for
> registrars, because they are actually doing different things, and the business
> environment is very different.

But the *concept* - that you provide information even if you don't 
directly benefit from it, is the same.  If you want to be the "go to" 
place for information, you have to provide information that you don't 
always directly benefit from providing.
> Google crawls the web to constantly refresh it's internal database; the data
> displayed is always out of date, and aging.  On the other hand, when you are
> checking if a domain name is available, the primary criteria is whether the name
> is available now.

This is a technical issue, not a business decision issue.  The technical 
details (of how you provide the information) are obviously different 
when you do a web search or a whois lookup.  The business decision to 
offer this information because it leads to a greater good (to becoming 
known as the "go to" source of the information) for your company's 
reputation similar.
> Also, the underlying search environment is very different.  A web spider
> traverses public links in data that people are frequently *hoping* will be
> prominently displayed in the search engines.  OTOH, checking for name
> availability is done using different protocols, some of them under costly
> contractual constraints.  Registrars and registries are actively hostile to data
> miners, and almost all of them rate limit queries.

You could similarly rate-limit queries to your search tool, right?  It 
seems like it would be relatively simple to age each query made from a 
given IP address, doubling the time you age the query before you pass it 
on to the registrar.

For example, set the time for the first query at .5 seconds.  The second 
query is "aged" 1 second before you pass it thru.  The third query is 
aged 2 seconds, the 4th is aged 4 seconds, the 5th is aged 8 seconds, 
etc.  The aging is based on how much time has passed since the previous 
query from that IP address.  For people who are manually entering 
queries and reading the results, they won't see any noticable slowdown 
until they have made more than 5 queries where the delay you now insert 
is longer than the time delay since they made the previous query.  E.g. 
only when they are making queries faster than 1 every 8 seconds would 
you start to delay the 5th query (so that it takes 8 seconds after the 
4th query before you send it to the registrar).

Automated queries would quickly be aged out to uselessness, but queries 
made by real people would be returned relatively fast unless they are 
quickly making new queries almost immediately after the previous query 
was returned.

This is just one idea, quickly thought out and not fully spec'd.  But 
you get the idea, it shouldn't be *that* hard to figure out a method 
that would work.  You could also add a Captcha, and/or mix both Captcha 
and aging.

jc


-- 
Eat sushi frequently. - Avi
[email protected] is the human contact address.
[email protected] is the list posting address.
See below URL for subscribe/unsubscribe and list options:
http://inet-access.net/mailman/listinfo/list