One of the projects I’m tackling on sabbatical is a community version of LibraryLookup. The service I wanted to create is described here: an RSS feed that’s updated when a book on your Amazon wishlist becomes available in your local library. Originally I planned to build a simple web application that would register Amazon wishlist IDs and produce custom RSS feeds for each registrant. But as I thought about what would make this service palatable to a community, I saw two problems with that approach:
- Familiarity. Most folks will not be familiar with RSS. If the primary goal is to get people using the service, rather than to evangelize RSS, it should use the more familiar style of email notification.
- Deployability. A web application needs to be hosted somewhere. In most communities, the library won’t be able to host the service on its own infrastructure. But if it’s hosted elsewhere, there will be a (rational) reluctance to take a dependency on that provider.
To address the first concern, I’m doing this as an old-fashioned email-based app. You subscribe or unsubscribe by sending email with a command and a wishlist ID in the Subject: header. And you receive notifications about book availability by way of email.
To address the second concern, I’m doing it as a client-side Python script, so that the only dependency is some version of Python and an Internet connection.
Because a library might not even be able to dedicate an email address for this purpose, I’m exploring the use of Gmail as the communication engine. In order for that to work, Python has to be able to make secure and authenticated POP and SMTP connections. Happily, it can.
The recipe for connecting Python to Gmail’s POP service is trivial:
import poplib
p = poplib.POP3_SSL(‘pop.gmail.com’)
p.user(‘USERNAME’)
p.pass_(‘PASSWORD’)
The recipe for connecting Python to Gmail’s SMTP service is less obvious:
import smtplib,
s = smtplib.SMTP(“smtp.gmail.com”)
s.ehlo(‘smtp.gmail.com’)
s.starttls()
s.ehlo(‘smtp.gmail.com’)
auth = ‘\x00USERNAME\x00PASSWORD’
eauth = base64.b64encode(auth)
s.putcmd(“AUTH PLAIN”)
s.putcmd(eauth)
This won’t work with no authentication, but neither will it work with the SMTP module’s login() which uses the wrong authentication type (i.e., LOGIN rather than PLAIN, I think).
Any POP/SMTP servers can be used, of course, so there’s no dependency on Gmail here, but it’s nice to see that Gmail can easily be pressed into service if need be.
It feels retro and trailing-edge to do an email-based app but, in order to make it familiar and deployable that seems like the right approach.
Great idea! I know that my wife would put this to use.
My initial reactions, which occurred not quite in this order but close enough:
1. You should provide both email and RSS, especially since I’m trying to get away from email as much as possible for such things, and I’m sure a lot of others out there are Just Like Me(TM).
2. But email would work since email-to-RSS gateways exist, including disposable email addresses provided by Bloglines and NewsGator.
2b. But there are scant few of such gateways that actually work 100% right (IMHO).
3. Providing RSS and letting users use the more numerous RSS-to-email gateways is more technically feasible.
3b. It {w,sh}ould be easy to mash up a front end for Aunt Tillie to sign up that signs her up for both services.
4. For a service that’s really a firing of an event and not a pseudostatic listing of available content (ala the RSS feed of a blog), email does seem to fit better. So the correct solution, especially for those of us not on the trailing edge, seems to be to address 2b) and let those apps that are truly suited for RSS go to RSS, and others go to/remain in email.
Jason B.
Hi There,
Jason : email and RSS : If a user can run Python, why can’t the user use RSS ? Create a screencast on how to use RSS reader from google and that should do the trick! You are succumbing to the recent MS antagonism for Power Users! It’s your power users who make your technology/tools popular — don’t ditch them :-)
BR,
~A
I’d certainly want to make RSS available as an option, but think about it from the point of view of a local library — or any small business for that matter. Having the web space to statically serve auto-generated RSS files, never mind a service to dynamically serve them, cannot be taken for granted.
There are two separate issues here:
1. A client-side script is more easily deployable
2. An email-oriented app is more familiar
It’s the combination of the two which argues for a primarily email-driven solution, with web registration and RSS notification being optional enhancements for those willing/able to host them.
anjan: I don’t quite understand your comment, seeing as I am one of the power users that I’m supposed to be neglecting… :)
I’m talking from the perspective of the users using the service, not from the perspective of the libraries deploying it, if that makes a difference.
Ditto re need for rss. If you WANT to take an e-mail-driven approach, because you’d prefer to design it as such, it’s you baby to build as you see fit. But more e-mail notification is not the way to go, and I don’t think rss is really a technical challenge for most at this point in time. Library Elf does a good job of combining BOTH(user choice) in a due/holds notification system that mashes multiple users/libraries in one neat package.
On 2nd thought. Wishlist -> library availability probably occurs too infrequently to justify monitoring via rss. You’re right to stick with e-mail notifictation in this respect.
“library availability probably occurs too infrequently”
Yes. For me it’s about once a month.
“I don’t think rss is really a technical challenge for most at this point in time.”
Not a technical challenge, no. But the vast majority of non-geeks do not seem to be in the habit of polling RSS feeds. And this includes those who often read blogs.
I hope this doesn’t sound snarky – I mean it in good faith, really. But: why not just request books you want via the Interlibrary Loan service at your library? Heck, you could keep the list of books you want on paper, and eliminate the amazon requirement too. (Okay, that was snarky. :)
Ultimately, a “netflix for books” option would be lovely, but in the meantime, most libraries can already get you copies of most any book you might want.
“But: why not just request books you want via the Interlibrary Loan service at your library?”
In our case ILL involves manual form-filling, so I do it rarely, but you’re right, for things I really want I should overcome that aversion.
I do like queueing up a bunch of books that I might want to read, or even just skim, should they happen to turn up. And there’s something kind of nice about receiving an alert about a book that you queued up months ago and forgot about.
I might be misunderstanding how this will be deployed.
Are you saying that it is intended for people who might not understand RSS but will run a python script?
I guess they will be mac users, unless I’m totally out of it with Python and it’s commonly used for Windows’ apps.
What I was trying to say is that mentioning running a Python script will scare more people away than having to sign up for Google Reader and subscribe to a feed.
An interesting thing happened at a presentation about RSS I attended a little back. The presenter was showing some non-technical people how easy it is to set up an RSS feed in Bloglines. She had it down to a couple steps n Firefox, and everyone was sufficiently wowed.
Then someone says — hey, could I set it up so I get an email when my Bloglines page changes? And someone else says, yeah, with maybe a list of the new links in the email, so I wouldn’t have to go to the Bloglines page?
The presenter tried in vain to explain this was the problem she was trying to navigate them around, but for those people they know they check email every day, but there’s just not enough of a critical RSS mass in their opinion to justify checking a Bloglines page everyday. Most of these people have never even changed their homepage…
I do appreciate having one interface for everything, be it mailing RSS feeds to me, or be it getting semi-disposable email addresses in my feed reader (such as Bloglines offers–except it’s not been reliable for me). If only I could get the email into my feed reader more reliably…
“running a Python script will scare more people away”
No, nothing like that. You sign up by sending an email request or by way of a web form. In this case I expect most people would choose the latter. You are then notified by receiving email or RSS. In this case I think most would choose the former.
Jon,
I just tried your code to send an email via Gmail’s SMTP server and it didn’t work. After doing some investigating, it seems that (at least in Python 2.5 for Windows) you no longer need to do the funky AUTH dance you were doing. The following code worked for me:
s = smtplib.SMTP(“smtp.gmail.com”, 587)
s.ehlo(‘smtp.gmail.com’)
s.starttls()
s.ehlo(‘smtp.gmail.com’)
s.login(‘myname@gmail.com’,’xxxxxxpassword’)
s.sendmail(‘from@gmail.com’,’to@gmail.com’,”’
To: To
From: From
Subject: Test
Just a test”’)
s.quit()
(I posted the full snippet, including the message body, for my own reference later. I didn’t realize that you had to form a valid SMTP message body in order to send a subject.)