mcdtracy

"who if anybody actually is the customer for lead generation sites?"

The customer for those sites is the company that is trying to sell a product or service. They use the whitepapers to locate potential clients for their product or service.

You build such a site and then sell the service to manufacturers and solution providers. Just prove that you can create effective prospect lists for them. The site has the appearance of offering impartial advice to someone seeking guidance in a purchasing decision:

"10 Things to Look for in Email Archive/Vault solutions" "How Enterprise Colaboration Products Stack Up in the Real World of Fortune 1000 Businesses" "Why You Next Tape Purchase May Not Be Your Last... Tape may not be dead yet"

Ba-da Bing 100 prospects for anything someone might need to sell.

Like most businesses the Internet will change the model of car sales. In a few years there will be fewer dealers and the prolonged negotiations and manipulations will from another era.

Costco is already moving into this space cooperating with local dealers to manage inventory and service. The number of dealers will collapse to the organizations that create an internet buzz around fixed and fair pricing and solid service.

Expect Amazon to move towards this highly leveraged model to connect buyers with inventory.

Here's my understanding of the potential for a scalability problem.

EXAMPLE: twitter.com has 24,650 twitter followers. If Dave gets 24,650 followers on an RSSCloud architecture then this is what happens when he posts.

1. Dave creates a 140 char post. Hs blogging software sends a notice to the cloud server that he has an updated RSS feed.

2. the cloud server sends update notices to the 24,650 subscribed "listeners" to Dave's "RSSCloud-twit-sream".

NOTE:It does not send Dave's new post text just the alert event.

3. the 24,650 listeners then do an RSS GET from Dave blogging server. This could create "cattle stampede" (i.e. slashdot effect) and many users may not get service when Dave's server is overrun. The server would likely be swamped with this massive interest in Dave's blog in a few seconds from these real-time subscribers.

At small levels of users the architecture is effective and elegant. At very large numbers it's missing an essential optimization. Only the "new blog" text should needs to be sent... maybe with the RSSCloud event for example.

An RSS GET will pull the whole string of recent blogs posts for all 24,650 users. A lot of excess text that most users already have from being real-time listeners anyway.

The RSSCloud Blogger's software needs to see a difference between a RSS GET for the recent blog text and an RSSCloud GET for the latest update text ONLY. Reducing the amount of text being sent out but a change to the protocols as described I think.

Of course, I could be way off base but I'm really trying to understand the overall architecture and the "realtime" problem this is intended to resolve for us all.

NOTE: If you federate the RSSCloud servers you just make the "GET" problem even worse. More demand on the blogger's RSS feed in a few seconds. It's like a user driven "slashdot effect". Post a 140 char message and notify the cloud and boom... you're server falls over.

I'll await corrections to my understanding.

NOTE: PubSubHubBub has an entirely different approach to the real-time optimization for bloggers. The Hub Server gets the blogger's new post text and the Hub Server forwards this delta to subscribed listeners. The Blogger's server never sees any excess traffic in or out. Of course, the PubSubHubBub service could require the resources of a Google, Amazon or Yahoo. A centralized service that could potentially have a "fail whale". Dave's RSS Cloud has a million "fail fishies".

Life as always is rife with tradeoffs. Go figure. YMMV.