I just heard back from Benjamin Trott, one of the authors of Movable Type, and he tells me that the new Google search (on both titles and excerpts) will be included in MT 2.2! Cool.
Also, Dave Winer (glad you're back from the hospital, Dave!) posted about the Google hack in today's Scripting News. I'm glad that he liked it. However, he may have misunderstood what I was doing - my hack doesn't give you a Google-It macro that just puts a link to a Google search. Instead, it actually performs the search when you build the page, and puts the related links right on the page as well. This removes a step from the process, and more clearly adds context to each entry. In addition, whenever the index page is rebuilt (like when new entries or comments are posted), the Google-created links are updated, even for old stories. If Dave is looking for a Radio implementation of this, he should look at Jake Savin's macro.
My comments: It's funny, just when I think that the USA has problems with the FCC and its Part 15 rules in the 2.4 GHz spectrum, I'm remineded that there are countries with even less freedom of the airwaves available. I'm also surprised that Wi-Fi itself isn't considered "low-power" - sure, it is lower power than say, Bluetooth, but surely not much less power than alarm circuits or meter-reader radios. Sounds more like an established player is looking to hold onto its turf.
Joltage will provide the registration, authentication, billing, payment processing and quality management services. Atlas will supply the broadband connection with speed and quality of service guarantees.
They are also offering a website promotion to receive a free access point when you sign up for Atlas Broadband and Joltage.
I'm still perplexed by Joltage's business model, but hey, maybe they can pull it off.
These are big moves, and show off two interesting points:
In the NTT case, they are agressively making moves in the 2.4GHz space even though the ministry of Posts and Telegraphs (the Japanese equivalent of the FCC) hasn't officially opened the spectrum for outdoor use. Reliable word on the street is that they will be opening up the 2.4GHz spectrum along with a piece of the 5.1GHz spectrum for use with unlicensed devices.
In the Singtel case, they are promoting the use of the Nokia D211 multimode radio card, which supports GPRS and 802.11b WLANs. This is, in my opinion, the sweet spot where the established carriers show their true muscle.
This is also a page that the US carriers should seriously consider, both as a bridge to their 3G rollouts and as a way to lock up the business user market and to force handset manufacturers to include these capabilities in their new handsets and PDAs. If and when this happens, say goodbye to the fledgling WISP aggregator model, a la Boingo and Joltage, and all the little WISPS sprouting up where wired broadband is hard to find. The ISP model (and WISP model) will be won by those with the most capital and the most locations; any other players will have to survive at the fringes and in the smaller niches where they can dodge the footsteps of the giants.
Hey, this happened before, with the wired internet as a model, and some of the bigger ISPs were able to hang on against the ILECs. But what is so surprising to me is how quickly these large carriers are learning from their past mistakes and are getting out there with service now.
Wow, I was pleasantly surprised with the rush of positive feedback from today's Google API hack for Movable Type users. A number of people asked for some new features, and given that it was only anoither 7 lines of perl code or so, I coded it up!
The new patch to MT 2.11 adds the following new features to the MTGoogleSearch tag. It adds the following new properties that will change the behavior of the tag:
In addition, if you use strip_html="1" inside the MTGoogleSearch tag, it will remove any html that Google replies with, including <b> tags that surround the search query terms.
This is a patch on the default build of Movable Type 2.11. If you've already installed my previous patch, it might be easier to just back out the patch and install this one.
By the way, I haven't done a lot of testing with the MTEntries query code (entries="1") so if you do use it, please send me feedback.
OK, I'm convinced. I've been toying with Movable Type's new Google APIs, and I've created something new and really cool.
With a 3-line hack to Movable Type's source code (gosh, I love having the source code to my software) I added a new function to its Google search capability - I can now do dynamic google searches on each and every one of the titles of my blog posts.
What's that mean? Well, look down at the bottom of this blog entry. You'll see a line that starts, "Related Stories:" followed by 10 links. These links are created by a google search on the words in the title of this blog entry.
The reason why I can do this is because Google has created a standardised way to automate queries to its search engine using a protocol called SOAP and the folks at Movable Type have created an interface that takes advantage of SOAP calls. All I needed to do was to add 3 lines of code to the Movable Type codebase to enable the capability seen in the "Related Stories" links below.
In addition, those links get updated each time I post a story - In other words, as Google indexes my pages and others like them, new stories show up whenever I update the index page with a new entry. Additionally, I could run a regular task to automatically refresh my Google related stories links for all of my entries each night as well.
If you're interested in the patch to the Movable Type codebase, I've included it below.
You can get the patch file at http://www.sifry.com/mt-googleapi.patch It is also included below:
+++ Context.pm Wed Jun 19 01:46:44 2002
@@ -1225,10 +1225,13 @@
sub _hdlr_google_search {
my($ctx, $args) = @_;
my $query;
+ my $title;
my $blog = $ctx->stash('blog');
if ($query = $args->{query}) {
} elsif (my $url = $args->{related}) {
$query = 'related:' . $url eq '1' ? $blog->site_url : $url;
+ } elsif ($title = $args->{title}) {
+ $query = _hdlr_entry_title($ctx);
} else {
return $ctx->error('You used
}
In other words, I added 3 lines to the code. The first defines a new $title variable, and the other two test to see if the "title" property is set in the MTGoogleSearch tag, and if so, it sets the $query variable to the entry title stored in the $ctx variable.
To use the new MTGoogleSearch functionality, simply use the title="1" property in the MTGoogleSearch tag.
I've put up my Movable Type index template file as well so you can see it work in context.
More information is available.
Certainly, this is somthing that needs further investigation. The company claims all sorts of neat stuff, including security, QoS, and other features. This can be performed in the CPE, probably not at the radio layer. The CPE can also be built very cheaply, and sold at about a $100 price point. A number of questions remain - are they using FHSS (old-fashioned 802.11 signals maxed out at 2Mbps and were FHSS) or DSSS? How do the CPEs react to multipath loss, reflections, and loss of line-of-sight to the brodcast tower? How well does the technology scale? Can it be used in a mesh configuration or is it point-to-multipoint? They claim that their low-cost CPE can be deployed without the need for an installer, which means it must be robust indeed.
This can be compared to Navini networks, which has developed a base station that uses phased antenna arrays (essentially smart antennas) to direct power at the CPEs, and simple CPEs that can be installed indoors.
Phased array antenna approaches allow for better penetration and even a notional non-line of sight capability, but they require a managed base station and can't be used for organic mesh networks, like the meshes that are created as a part of Nokia Rooftop's or Sky Pilot's solutions.
These boosterish pieces pay little to no attention to security or management issues, which makes me wonder how Boeing and the Marines perform them (if at all).
The short answer? Maybe -- if you are one of the growing band of people who use home-made equipment to increase the range of 802.11b hotspots.
Sifry's Alerts' comments on this development:
This is good - it removes a potential issue that overshadowed the widespread adoption of wireless technologies like 802.11b. I think the FCC would have ruled against them anyway, for the following reasons:
1. They were asking for a legislative fix to the laws of physics. This Sirius request included an OOB limit of -158dbm which is 8 dbm below the thermal noise floor. In other words, the normal evaporation of water into clouds makes more noise in the 2.5GHz spectrum. Besides, other noise generators much closer to the receiver emit a much larger noise profile. The spark emitted from a spark plug is one example.
2. Significant opposition from other established industry players, including Motorola, Intersil, Intel, and others.
3. The FCC's emphasis on reducing the digital divide. The FCC was being asked to decide if it was more important to have high-end radio between cities or cheap, high bandwidth connectivity in low income neighborhoods, and I think the public interest would have won on this one.
So, count one for the good guys today! And don't rub Sirius' nose in it - they did the right thing.