I'd have to agree with this:

According to Nokia chief strategy officer, Tero Ojanperä, Skype must branch out or die. "Someone needs to make money... [Skype] cannot survive on voice calls alone, it needs to find a business model," he said.

Shype (Skype) will die if they don't work with standard open protocols and forget about its proprietary stuff.

Lot of talk about Ajax being a pull (poll) only technique that has its limitations. This is true but there are also implications for using open http socket connections as well. I've made comments over there and quoted here:

Brent and I thought of using an open connection instead of a polling connection when thinking about scalability for BlogChat but decided against it. Although clients will be polling at some interval, the number of concurrent connections at any one time is manageable and works very well in a distributed webserver farm. With an open connection method like mod_pubsub, resources are held the whole time while a client is connected. If the server is overloaded all of the clients are affected and likely lost under severe circumstances. With a polling type of scenario one client may be affected for that instant it hits that particular server in the farm. Of course there are advantages and disadvantages to both methods that should be weighed depending on the application you are developing.

Rohit Khare weighs in about whats next after Ajax here. I find it a bit interesting the mention of KnowNow (which I won't like to now) since according to Phil Windley, Rohit is a founder of KnowNow.

Actually through Google cache result it seems mod_pubsub open source project was the basis of KnowNow. That info has been pulled off of here:

Dr. Rohit Khare. I am a graduate of Prof. Richard N. Taylor's software research
... the open-source Mod_PubSub project that eventually grew into KnowNow.

Oh well, I guess they didn't want anyone to know that fact.

Another Ajax type web chat has popped up on my radar. Its called ARSC (A Really Simple Chat) and can be found here.

Looks like web chat apps are going to be the thing to do to show off Ajax. Makes sense. Way back a few years ago Brent and I wanted to create something with Brent's JSRS library that we could showcase but we could not came up with anything that was interesting. We had been using JSRS in private projects for some time before this. One day Brent had a need (or want) to communicate with his blog visitors so he started coding (in an evening or something like 48 hour time frame) what turned into BlogChat eventually. It was way crazy the first couple of days as the word spread through the blogosphere. At one point I was sitting in the chat while tons of people dropped in giving feedback as Brent hammered out some small bugs and tweaked things here and there. It was essentially a 48 hour beta period. Crazy times.

BTW, for those who don't know JSRS (Javascript Remote Scripting) uses Ajax techniques (just 2-3 years before the name was coined).

I'll let Brent add some comments here and potentially point to some interesting blog posts from those crazy days.

Since the Ajax hype we have noticed an increased interest in BlogChat. Lace is a similar type thing you can find here.

I suppose Brent and I should spruce up BlogChat a bit and bring it into the current year. We really haven't touched the code in over two years so its due for a bit of work MAYBE. There might be some minor bugs that need squashing as well but we haven't really had any significant reports from our users about any issues in many moons.

We've been extremely busy with other projects (like SimpleFilter to mention one) to really spend much time on BlogChat. But since this renewed interest in Ajax and Brent taking part in the Ajax Summit perhaps we'll mess about with the technology more these days.

This is a totally unacceptable suggestion by Microsoft to do Remote Debugging Across Domains. I actually just want to debug while not being part of any domain at all. Here is the ridiculous suggestion as found here:

Remote debugging with the default transport uses DCOM. DCOM security prevents remote debugging across Windows NT domains and across the public Internet unless the domains have two-way trust.

Remote debugging using the TCP/IP (native only) transport depends on IP ports that will be closed on most firewalls, preventing remote native debugging across the public Internet.

If you need to debug across domains that do not have two-way trust, you can use Terminal Server.

To debug across domains that do not have two-way trust

1. Use Terminal Server to log into a machine on the other domain. The machine you log into should have Visual Studio installed.
2. Launch Visual Studio on the machine you have logged into under Terminal Server.
3. You can now debug an application on the machine you have logged into under Terminal Server or use remote debugging to debug an application on another machine in the same domain.

On Windows XP Professional, remote debugging is disallowed by default, because of the default security setting for "sharing and security model for local accounts." To debug between two Windows XP Professional machines on different domains, you must change this setting.

To change the security setting to allow debugging between Windows XP Professional machines on different domains

• Perform the following procedure on both machines:
  1. From the Start menu, choose Control Panel.
  2. In Control Panel, double-click Administrator tools.
  3. In the Administrative tools window, double-click Local Security Policy.
  4. Under Security Settings, open the Local Policies folder.
  5. In the Local Policies folder, select Security Options.
  6. In the Policy column, find Network access: sharing and security model for local accounts and double-click on it.
  7. In the Network access: sharing and security model for local accounts dialog box, change the setting to Guest only - local users authenticate as Guest and click OK.
  8. Close the window and restart the machine.

You can now do remote debugging using the same user name on both machines.

You mean to tell me I have to install all the development tools on the server. This is a development server but I still don't want to load it up with all kinds of crap. Not to mention I might as well throw out my workstation and go sit in the server room at the console. This is the kind of domain wonk crap I have to put up with when working on Microsoft stuff. Not to mention wasting 90% of my time leaving 10% of it to actually getting something accomplished.

Two or three years ago a business partner and I researched software to do speech to text in order to index audio from video files for a company we were looking to start. The technology was available but expensive.

I remember discussing this with Adam Curry about a year ago when he was looking for something similar.

No surprise to see a new search engine based on it at Podscope. There are probably others.

Good thing I didn't hold my breath as I pointed out here!!

From TechDirt:

Early last year, Bill Gates announced that he was concentrating on the spam problem and had a few ideas on how to stop the problem. Of course, all of those ideas sounded like ideas that others were already trying -- and there was still plenty of spam. It's now been a year since Bill Gates said that his methods could get rid of spam in two years and it's not clear if his efforts have done very much. Certainly, Microsoft has been suing spammers, and some claim that the overall amount of spam has been decreasing a bit. However, we're still quite a long way from getting rid of spam -- which means the special department at Microsoft whose only job is to manage Bill Gates' spam (even if it's not as much as we were originally told) will probably still have plenty of work to do a year from now.

Here are some interesting Remote Scripting / Ajax examples. See http://www.cmswatch.com/News/Article/?421

And of course checkout this.

I guess I should mention BlogChat as a Remote Scripting / Ajax example.