An Answer for Twitter OAuth-pacalypse

For your smaller Twitter API projects, bash scripts etc, we have launched SuperTweet.net in case you don’t get OAuth implemented by the time Basic Auth goes away June 30, 2010. It’s a Twitter proxy – you use Basic Auth to talk to the proxy, and it uses OAuth to talk to Twitter.

SuperTweet.net Access Credentials

For example, to send a tweet, use the http://api.supertweet.net/1/statuses/update.format such as:

curl -u user:password -d "status=playing with cURL and the SuperTweet.net API" http://api.supertweet.net/1/statuses/update.xml

The password shown in the example above is never your real Twitter password, but a separate password you set up just for use with the SuperTweet.net API – As with Twitter OAuth, you can revoke, change, or disable that password without any impact to your real Twitter password or Twitter account.  Also, you can deauthorize the SuperTweet.net API application itself on Twitter.com if you think it’s being bad, again, without affecting your real Twitter password or other Twitter applications.

Learn more: http://www.supertweet.net/

Subscribe to the comments for this post

Some iPad thoughts

A little birdie told me that you (all seven of you) have been waiting anxiously for my thoughts on the iPad – the definitive iPad perspective.

Here you go.

First, I don’t have one myself yet, but I have had a chance to play on friends’ iPads. Second, while I don’t consider myself an Apple apologist, some of my friends accuse me of being so. And, finally, before you think I’m an iPad hater, I want to preface this whole thing with the fact that I do believe that iPad represents a step into the future and while I might not be ready to pay $600 for one today, I expect to have a device like this in my household sometime in the not too distant future.

A few jabs… look away if you can’t stand anything negative about iPad

Upon finally getting my hands on a real iPad to play with for the first time, my first reaction was disappointment in the display quality.  I had been pumped up to expect pictures, video and web sites to be “gorgeous” and “stunning”, but for me it was more meh.  Perhaps my expectations were just too high. Some examples:

Video. Maybe it’s just me, but I thought the video in particular was okay,  but not stellar or HDTV beautiful. It looked to me like typical medium-rez PC video, pixelated, blurry, and laced with digital artifacts – granted, on a bright and glossy screen.

Games. I was also not that impressed with games.  iPad doesn’t compare to a $300 $159 Xbox and $150 HDTV. My son is a gamer and he wasn’t impressed at all either.

Web pages. The browsing experience is fast with a nice UI generally. But, as others have noted, the typography could be better.

So how does it change the world?

In what could be characterized as “flame-bait”, Daniel Eran Dilger names 19 things iPad will kill including: Kindle, Netbook PCs, PSP, DS, Flash, Silverlight, MS Office, Windows Media Center, set-top boxes, TiVo, Chrome OS, and Android. While I take issue with some of the history and reasoning in Dilger’s post, I generally agree with the conclusions. That’s a lot of carnage.

But that’s already been said.  Probably every idea regarding iPad has already been said somewhere out there in the Internets, but here are a few ideas I haven’t seen yet.

Does it spell the end of open-computing?

There are a lot of fears that iPad marks the beginning of the end for computers as we know them. That is, the kind of computers that let us download and buy software from wherever we want. I think this is partially true. I don’t think “real computers” go away, but iPad (and its future offspring) certainly change the role of real computers. It won’t happen overnight, but they will be shifting into a niche role, for high-end verticals. For one thing, you still need a “real computer” to develop the software that runs on the closed systems like iPad.  These old-school type machines will still be used for other high-end applications, like professional photo work, video etc.  They won’t go away completely, but over time, “real computers” become less mainstream and most people get all they need from “closed” machines like iPad.

I think there will be room for hybrids, computers that can act like iPads, and iPads than can act like computers. Consider an iPad-pro that is essentially a jailbroken iPad. I think iPad will (or should) become an App on Macs (essentially an end-user version of the iPad emulator we have in Xcode) – sort of analogous to how Front Row makes AppleTV an App on Macs – oh yeah, and Macs will have multi-touch touchscreens.

Does it replace the laptop?

Here’s my take. Yes, for most people… but not entirely.  Or, in other words, maybe my answer is really “well, sorta.”  You see, I think the laptop and the iPad will converge, into a spectrum of machines ranging from, on the low-end, closed devices that look like the iPad of today and, on the high-end, devices that look a bit more like a laptop of today, or more like the tablet-PC type machines.  But these higher-end machines will be more niche, less mainstream.

The iPad type device will be the core device and there will be a range from more phone-like ones, smaller and more portable, to larger, more “coffee-table” ones.

You’ll drop this semi-portable iPad type device on your desk and it will sync up to your bigger HD monitor and physical keyboard (for those that want the old school type PC) and will act mostly like a PC as we know it today.  You’ll do all the stuff people do, web surfing, documents, presentations, music, video, greeting cards (yes it will sync to a printer too) and of course email, chat (and blogging) etc.  For most people, this is all they’ll ever need and the iPad becomes their laptop, desktop, mobile, coffee table, and multimedia home entertainment device. Done.

In a desktop mode, the iPad may physically also serve as the equivalent of the mouse, or i.e. one of the input devices of this “docking station” computer-like setup.  There may even be docking stations that look like a laptop as we know them today. Some peripherals will connect physically. Most will connect wirelessly (finally, Bill Joy’s Jini dream comes to life).

This future is a docking station, cloud-computing, traditional computing hybrid model.  Some data and apps are in the could. Some are local, or cached in a hybrid cloud model. Some computing tasks happen on the iPad “core” device. Others occur within separate CPUs in the linked up and networked peripherals (this already happens today, with routers, network storage, our TVs, Bluray players, etc).

At the low-end (and the largest mainstream segment) it’s a closed world, where people get Apps from approved app stores and that’s fine with them.  For a price, on the high-end there will be more “open” platforms, all the way up to the top of the stack, the platforms used to develop the code for the “closed” platforms.  There will be some layers in between: iPads that are more “open”  as well as traditional-style computers that are more “closed” and some hybrids in between.

So, in the end, I don’t think iPad spells doom and gloom or the end of software innovation. Things are going to change. There will be winners and there will be losers. But I think there will be opportunity throughout the value chain with wealth spread around in a long-tail manner. Yes, the vast majority mainstream users will be on “closed” platforms (by today’s definition) but that may be a good thing, in some ways – and the iPad is certainly not really “closed” compared to, say, a cable TV set-top box. People can still get third-party apps, and (probably) users will still be able to use web apps without Apple approval.

Final thoughts, Immediate uses for iPad

On the coffee-table. For me, the first use is as a living room device, a coffee-table browser basically. This is particularly true of this first generation of iPad that doesn’t have cellular data, so it will only work in Wifi hotspots, making it somewhat less useful as a mobile device. I think before long, we are just going to expect to find an iPad on the coffee table.

Laptop substitute. There’s also the “almost laptop” role.  I’ve tried countless devices over the years for this purpose (including the Sharp Zaurus and Nokia N800) and I’ve always come back to a real laptop. For everything I can’t do on my iPhone, I pretty much need a real laptop, particularly if it involves connecting to external hardware, like flashdrives, printers or VGA/DVI video projectors. For me, the iPad in its current form may not be adequate, sitting in limbo between the iPhone and a real laptop, but there may be some times when it would work for me as a substitute for a laptop. I think for a lot of people, including journalist Larry Magid, the iPad serves this role just fine already, in its current form.

Demos. I think the iPad will be the new hand-held interactive brochure. I don’t do a lot of this kind of activity myself, but I think these will be all over trade-show floors, showrooms, etc.

Contrary to the views of many, I don’t think the iPad, or at least not this first version, will be that huge of an eBook reader… yet. I think it will get there, but I think initially people will use it, especially the first wifi-only iPads, in the above roles more than as an eBook reader.  Nor do I think it will be a big game machine – people will play games on it for sure, and eventually it surpasses PSP, DS etc. – but in the near term, partially due to cost, pure gamers will stick with other platforms/devices.

Any bets on how soon before I get an iPad?  When are you getting yours?

Subscribe to the comments for this post

Java culture rant

As some of you may know, over the last year or so I’ve been spending more time with larger and larger Java-based server-side projects (including Quick Bit Notes, Twitmart, Litetext, and iSpykee). In this process, I’ve had to “catch up” to the Java state-of-the-art and get reacquainted with the Java culture.

Much of this has come with the great patience of my friend Mark Petrovic who has helped me immensely in this endeavor. It has been an overall very positive experience, to the point that Java is now my first choice starting point for server-side and web-app projects.

So here’s the rant:

What is it with Java tool developers that they like to “improve” their APIs in non-backwards compatible ways on a semi-regular basis?

Perhaps I’ve just been “lucky” but I’ve experienced this with many of the key packages I’m using, such as Jetty, Twitter4J, and Lucene.  It’s almost like it’s part of the culture to break things, just to shake things up.  Maybe it’s a “purity” thing and they always think their API needs to be cleaner and the only way to get there is to break it (again).

One of the biggest hassles that come with this culture is that it makes it really hard to come up to speed on a tool because you have to also study the full history of it, scattered across countless message boards, blogs, and websites (oh my!).  When you run across examples showing use of the package, they often only work with the specific version of the package/tool from some point in the past. Of course these examples seldom state which version they were written for nor are they updated to bring them current to the latest version. Coming out of the blue, being new to one of these packages, it’s really hard to tell when the package diverged and in what way the rules changed.

It seems like every Java tool developer thinks their users are, or should be, spending every waking minute on their specific development-talk forum.

Is it just me? Am I really the only one who struggles with this?

Subscribe to the comments for this post

Litetext for rendering text into a bitmap on Google App Engine Java

While developing Quick Bit Notes, I realized that the Google App Engine “sandbox” for Java doesn’t support AWT or other graphics Java classes, so I put together a simple “old-school” text rendering class that’s compatible with App Engine, called litetext.

This small package (less than 1000 lines of Java code) was developed to provide a small and simple package for rendering text into an image (bitmap). It was developed for Google App Engine use where AWT and BufferedImage et al do not exist. This small utility can be used to render text on App Engine within the constraints of the JRE Class White List. This is derived from the “pbmtext” utility from NETpbm Copyright (C) 1991 by Jef Poskanzer.

These are crude black-and-white bitmap fonts – no anti-aliasing. A small number of BDF fonts in fixed-sizes are bundled into the package: Courier, Lucida-Bold-Italic, Lucida-Medium, Lucida-Medium-Italic, LucidaBright-DemiBold, LucidaTypewriter, LucidaTypewriter-Bold, and a default serif font.

The following code snippet demonstrates use of litetext on App Engine:

You can grab it via SVN at http://code.google.com/p/litetext/

There are docs on the project site for adding fonts and an example demo servlet is included. See the Live Demo.

Use this command to check out the latest project source code anonymously over HTTP:

Subscribe to the comments for this post

Introducing Quick Bit Notes

I’ve released Quick Bit Notes (QBN) as an experiment in an unconventional method of person-to-person asynchronous communication. One person drops off a personal note for another person. That note is stored and presented in image form to the recipient. The actual text is never stored on QBN and never transferred over the wire when the recipient views the message.

QBN offers an alternative to complicated software, shared keys, and so on. All one needs to use the service is a browser and Gmail email account.

The service is running on Google App Engine for Java and is available as open-source on Google code: http://code.google.com/p/quickbitnotes. It should be relatively easy to deploy in your own App Engine appspot “slot” (refer to the README in the source archive).  If you want to be an SVN contributor to the code, just let me know.

In the process of developing Quick Bit Notes, I also created a small Java text-rendering library, based on NETpbm, that operates within the constraints of the Google App Engine JRE “white list”. This is a stand-alone JAR that can be used with other App Engine projects and is also available as open source on Google Code: http://code.google.com/p/litetext/

If you’ve followed along, by now you may see some applications of QBN for your own personal communications. If you’re not seeing it yet, QBN is probably not for you, so please don’t waste your time or mine spending time on it. And, please, dear god, don’t ask me questions like “what’s the distribution strategy” or tell me all the reasons why this service will never take off and how Twitter is so much better.

Subscribe to the comments for this post

Experimenting with Google AppEngine for Java

A while back, I noted that Google had announced that they would be supporting Java on their AppEngine cloud computing platform. I finally got around to working on a significant AppEngine for Java project (something beyond “hello world” or the demo “Guestbook” app).

Working with my friend and colleague, and serious Java guru, Mark Petrovic we decided that a good “Goldilocks” candidate, that was neither too big, nor too trivial, was the experimental service Twitmart.org, a classifieds marketplace mashup, using Twitter APIs.

We decided that “porting” an existing web-based application rather than inventing a new one made more sense because this way we really didn’t have to think a lot about the design or functional specifications.  We already had them. We just had to think about how to implement to those specifications on a Java-based web application platform, and specifically, the Google AppEngine for Java platform.

With the Twitmart application, the first thing to address was that the site uses Restful-style urls (as opposed to a fully Restful architecture, for you Rest weenies). This introduces a number of issues. The AppEngine for Java platform implements the venerable, but now decade-old, Java Servlet API. Servlets don’t naturally support the clean urls that are essential in modern web applications.

Bad => /post.jsp?type=area&hash=forsale&postid=hKqo1
Good => /post/area/forsale/hKqo1

One way to go about this is to do it the old fashioned hard-coded way and manually parse urls and forward to servlets for the action. We considered doing so, as a last resort, but it would be painful and potentially a maintenance nightmare.

We had hoped to use Jersey but found that it was not quite there yet in terms of compatibility with Google AppAngine, although it looks like there is progress and we will see at least a subset of Jersey supported on AppEngine at some point. For this project, we decided that the outstanding issues with Jersey on AppEngine were more than we wanted to deal with. Since Twitmart is a web site rather than a web service API, perhaps Jersey isn’t quite the right platform anyway.

Regardless, we went with Restlet, which does support AppEngine in their latest unstable releases. Going with Restlet meant that we also needed a compatible template engine to replace JSP. We went with Freemarker which is supported as a Restlet extension.

There are many Java libraries for accessing Twitter APIs. We went with Twitter4J which appears to be the most AppEngine friendly (and it’s a nice, clean API too).

With all of these building blocks in place, the port of Twitmart to AppEngine for Java was mostly a matter of grinding it out. Here’s a bunch of stuff we learned in the process:

Restlet, Freemarker, and Twitter4J work on AppEngine

The Twitmart application doesn’t exercise every part of any of these tools, but the basics clearly work. That’s nice to know. We will use these again on future projects.

Servlets and Restlets can co-exist

A few of the operations that Twitmart does were better suited to traditional servlets. With some effort, we probably could have made them work as Restlets, but it was much quicker and easier to make them servlets, so that’s what we did. And it works. Servlet urls are directed to servlet classes in the usual way in the web.xml config while everything else is passed through the Restlet adapter/router class.

The AppEngine Text class overcomes the 500-character limit of Strings in the datastore

The datastore will only accept Strings of up to 500 characters. To store larger text, one must use blobs. AppEngine provides a Text class that makes this pretty easy – but it does make your application more AppEngine specific. A Text object cannot be viewed in the datastore viewer (admin panel) and they cannot be indexed or queried.

It’s not that hard to put arbitrary Java objects into the datastore

The Twitmart application accepts images uploaded by users to display with classified ad postings. Since AppEngine has no writeable file system, these “image files” must be placed into (and retrieved from) the datastore.  This turns out to be pretty easy, as long as the size of the data conforms to AppEngine’s limits – e.g. 1MB per datastore entity (see http://code.google.com/appengine/docs/java/datastore/overview.html)

Objects in the datastore have unexpecetd dependencies

I don’t know if  Java bytecode ends up in the datastore or not, but it kind of feels like it does. When we rearranged some classes, we discovered that datastore records using those classes failed with ClassNotFound errors. I guess we should have expected this, but it’s something to keep in mind – once something is written to the datastore, never move the class.

As I’ve noted before, the AppEngine datastore is not an RDBMS, despite providing a query capability that might make you think otherwise at first glance. The AppEngine datastore is based on the BigTable storage system. BigTable follows a very different philosophy than traditional RDBMS and, as a result, imposes many important restrictions. Knowing this from prior work on Taglets.org and other projects on AppEngine for Python, I knew about these restrictions and, in fact, the Twitmart application doesn’t make any queries at all; it always retrieves objects (records) by key and never via query.

Another lesson from our experience with the Python AppEngine was “be prepared to move off AppEngine” (for any number of reasons). This means trying to structure your application such that moving to a standard platform will not require a complete re-write. One place to start is to avoid any com.google.appengine.* imports. In the case of this Twitmart app, the only place we do that is for the special com.google.appengine.api.datastore.Text class (in order to store text strings larger than 500 characters). This is isolated to a couple of Java classes in this application, but in a larger app, or if such things found their way into too many places, it would be best to write abstraction libraries of some kind to make it easier to separate out AppEngine dependencies later.

The Twitmart app, as written, should run on any standard Java web application platform, such as Jetty, pretty easily. However, that said, while using JDO as the data management interface works, in theory, as a way to make your application work on AppEngine and on a standard platform, it might not turn out to be the best way, or the most common technique for managing data on standard web application platforms, in practice. In many cases, you would probably want to add an abstraction layer around your data models to make it easier to swap in different low-level APIs. I think in general, the AppEngine for Java platform makes this easier and more natural than the AppEngine for Python platform, where it takes a lot more effort to keep your app standard-platform ready.

The Twitmart port is not done. There are few functions left to implement and a few things still to fix in terms of better exception handling and related cleanup and enhancement, but the primary functionality is operational.  In practice, even with light usage, it is slower on AppEngine than it was on my own server, but I guess that’s the price you pay for “free” – so much for scaleable. I guess the theory is, on AppEngine it will show similarly poor performance for a dozen users as it does for 100,000 users.

Summary

If I develop more AppEngine apps, I’m going to use the Java AppEngine for sure over the Python AppEngine. Unless there is some really compelling reason (like a specific library I want to use) I don’t see me writing another App Engine app in Python ever again.

While I still don’t think Google AppEngine is ready for anything too important yet, if it ever will be, having a Java version is a big step in expanding the possible uses of Google’s cloud computing platform, IMHO, and I will almost certainly deploy more experimental applications like Twitmart using AppEngine for Java in the future.

References:

• Google App Engine for Java
• Restlet
• Restlet edition for Google App Engine
• Freemarker
• Freemarker extension for Restlet
• Twitter4J
• Twitmart.org

UPDATE October 16, 2009: The performance on App Engine was so poor that we had to move the Twitmart.org site off of App Engine and back to one of our own servers.  Details here.

Subscribe to the comments for this post

Google App Engine adds Cron and Java

Google today announced that they will be supporting Java on their GAE cloud computing platform.  I signed up for the beta, but don’t know when/if I’ll be approved.

I also saw that the platform also now includes a cron mechanism to run scheduled “jobs”, see: http://code.google.com/appengine/docs/python/config/cron.html

This could change things.  It will be interesting to see how (if?) Amazon responds.

Subscribe to the comments for this post

iSpykee – Open-source Spykee for iPhone

I finally finished making my previously mentioned iPhone hack for Spykee into a form I could release for public consumption.  It’s still not perfect, but at least I’ve removed external dependencies so it can be installed without too much difficulty.

Spykee wifi robot interface for iPhone and iPod Touch

Basically you run the “controller” software on your LAN (the same LAN as the Spykee robot) and then use your iPhone to control and interact with your Spykee robot from anywhere.

The “controller” software is available as open-source and can be used on Mac OS X, Windows XP/Vista, or Linux/UNIX systems. As far as I know, this is the first release of an open-source implementation of the (binary) Spykee protocol. This software is provided in “C” under the BSD license, so it could be used as a basis for other home-grown Spykee applications, including motion detection, stealthy audio snooping etc.

iSpykee currently supports moving the robot, by touching areas of the video image: left, right, forward, and back; changing the robot motor speed (”Turbo mode”); turning the headlight on and off; taking a snapshot of what Spykee is seeing; turning “Video surveillance” (motion detector) mode on and off. It also supports a “low bandwidth” mode that can be useful when using iSpykee from a slow network connection (such as Edge).

Please check it out and join the iSpykee Google Group.

Updated to note that the “controller” software now works on Windows too.

Subscribe to the comments for this post

Google App Engine teases, but ultimately doesn’t deliver

This blog should perhaps have been named “My Rants” – but I guess that could be said of most blogs.

In case it’s not obvious yet, this is officially a rant.  But I will try to keep it short, an “Executive Summary” rant, if you will. In fact, that’s all I have energy for anyway.

Sling a stale slice of pizza, and you’re sure to hit a slew of twenty-somethings that will tell you what a “super cool” language Python is and what an “awesome” platform Google App Engine is. Perhaps they’re right.

I won’t go into the Python language here. I will, however, simply quote from the unpublished rants of a well-known and well-respected author I was recently re-reading:

I think they should have just named the language “Underscore”.. and the source files could have a “._” extension.

However, Python is not the worst of GAE’s problems, not by a long shot. In the name of executive summary brevity, I’ll jump right in.

1. “GQL” and the Datastore – I don’t know who Google is trying to kid here by hinting that the “datastore” is somehow like “SQL”. God help you, if you fall into that trap. It must drive any real RDBMS expert mad.
2. urlfetch – only works on port 80 or 443 and times out after a few seconds.
   
3. mail.send() – can’t send to more than a few addresses at a time, whether invoked once for all recipients, or using multiple invokations.
   

All the above should be prefaced in the GAE documentation, in huge red letters: DO NOT EXPECT THIS TO WORK because they don’t, at least not in practice to do anything real.

In theory, Google says a request can run for up to 10 seconds. In practice, it never will because it will hit quotas before that, or it will fail because of urlfetch timing out if it makes calls to web services (like Twitter API, Facebook API, or whatever) on the back end.

Without this basic functionality, there isn’t much a GAE app can actually do, especially if it gets popular.  Without these functions, your app can’t connect to anything. It’s like a computer without the Internet – not very useful. And the worst of it is, you don’t find out they don’t work, until you get to the point of trying to actually use them, which means you’ve already put in all the effort to learn the platform and write code for it.  I say, for now at least, don’t waste you’re time, unless you are really bored and like punishment.

If your app is small enough, and doesn’t do much more than generate slightly dynamic content using templates, it might work on GAE.  Otherwise, stick to a real platform. Paraphrasing the words of a co-developer:

I think we’re at an inflection point:  forge ahead with GAE culture, or spend that time scaling and fortifying the app somewhere else.  I mean, if our app really takes off, we are unequivocally screwed on GAE; run over by a truck.

Google App Engine has promise, if they can resolve these issues (and a number of others I’m leaving out). It comes down to whether Google will get serious or not and that’s not their style or history, so we’ll see. This cannot be just another “G” self-service, zero-support platform, if they ever want to support real companies deploying real applications and services.

At the end of the day, Google teases, one might even go so far as to say tricks us, into believing they are providing a platform of substance and merit, only to disappoint those of us who took them at their word.

See Also: Aral Balkan – Why Google App Engine is broken and what Google must do to fix it.

Subscribe to the comments for this post

Taglets.org API examples and sample code

Taglets.org is founded on the idea that no matter how brilliant you and your coworkers are (or think you are), there are always going to be smarter people outside of your company. That’s why it’s an API and platform first, so that people smarter than we are can exploit the platform in ways we would never think of. Originally, we weren’t even going to build a user-interface at all, but then we decided we needed something to demonstrate the platform and as a quick-start for non-developer end-users, and thus, we built the www.taglets.org website.

However, the platform and API are still the focus. Twitter, Friendfeed, Facebook, and even the iPhone, have all demonstrated that an API is a powerful way to facilitate prototyping and innovation.  The openness of the Internet itself is perhaps the world’s most successful example.

It is with that in mind, that we have been working to provide some tools to jump-start development with the Taglets API.

Taglets API for Java Developers

Mark has released an open-source package that makes it easy for Java developers to use the Taglets API. It works with the Groovy scripting language. Download it here: http://code.google.com/p/tagletsapi/

PHP POST Outlet Example

Mark also built a very simple PHP script that demonstrates how to write an HTTP POST Taglets outlet script. In the settings for a tag, there is an option called HTTP:

In the data entry field, you put the url of a script on your web site, such as http://myserver.com/myscript.php. When a comment is posted to that tag, the Taglets.org platform will invoke that script using HTTP POST with the tag name and comment as parameters (as though a user had typed them into a form and clicked ‘Submit’). The example shows how a script can capture the tag comments to store them, and later display them to users. Most importantly, it shows how to write a script that interfaces to the Taglets platform as a HTTP POST outlet. Get the PHP code here.

Taglets.org Wordpress Plugin

We’ve also put together a simple Wordpress plugin called Taglets Feeder that will send comments to tags when you publish a blog post.  As every WP user knows, when creating a blog post, you can specify tags associated with the post, as shown below:

For each tag specified (”taglets” and “wordpress” in the above screenshot), when you publish the post, the Taglets Feeder plugin will send a comment on that tag to Taglets.org that looks like: “[post title] [short url]”

Everyone (and every “thing”) following those tags at Taglets.org will receive the comment via the “outlets” they have specified, email, twitter, or HTTP POST.

In addition, the plugin has a setting for a “fixed tag” as shown below:

This “fixed tag” setting causes the plugin to send a comment to that specified tag, in addition to the tags specified with the blog post. This can be used, for instance, to always send a comment to a tag named for your blog (e.g. “mrblog”), whenever you publish a new blog post.

Of course the plugin includes the PHP source code and is released under the GPL to use as a base for anyone wishing to expand on it.

Get the plugin from Wordpress.org:  http://wordpress.org/extend/plugins/taglets-feeder/ or type following directly on your WP blog: /wp-admin/plugin-install.php?tab=plugin-information&plugin=taglets-feeder

Subscribe to the comments for this post