Disqus - Latest Comments for esjewett

Re: Statistical misunderstandings and Google Book Search

esjewett — Mon, 07 Sep 2009 10:15:25 -0000

Indeed, that would be a mistake. However I have never seen an actual example of such a mistake linked from a blog containing a complaint about mixing up translators and authors in Google Book Search. Much less an attempt at analysis of the pervasiveness of these mistakes as compared to similar mistakes in library metadata. Perhaps I've just been very unlucky in the blogs I've read.

Re: Introducing jsglue

progrium — Fri, 15 May 2009 07:38:54 -0000

Well, as for an API, I'm trying to stay close to the Rack/WSGI style environment. I use Jack (https://github.com/tlrobinson/jack/tree) for the Javascript environment in Scriptlets. Perhaps you can do the same. However, I do have some special things in the environment that we may want to add to a standard API for services like these.

You should subscribe to the Webhooks mailing list and post progress there. :)

Re: Introducing jsglue

esjewett — Sat, 09 May 2009 00:22:15 -0000

Thank you! I would be delighted to continue this conversation.

Unfortunately as soon as I posted this work started to heat up, so I haven't been able to do much more on it. I think the next steps are to clean up the API to the request (in the javascript) and get some working examples cooked up.

One thing that I'm very encouraged by is that javascript handlers should be relatively transferable between services like scriptlets.org, this one, and other similar services. Hoorah for interoperability.

What I'd really like to see is some type of "scriptlets" API (you know, Rack/WSGI-style?) so that these handlers are fairly portable between engines. If you'd like to work on that together, or just continue to discuss the best way to do this, I'd be delighted!

Re: A RESTful ESME API

esjewett — Sun, 15 Feb 2009 09:06:27 -0000

Thanks!

I agree with you on the format issue. I'm partial to the id.format approach. That's not really a component of REST vs. RPC though, so I thought I'd leave it out for simplicity. If we're talking about fully specifying an API then it needs to go in, for sure.

I'm not very familiar with how long-polling works. I assume that we need to communicate to the server that it needs to keep the connection open for some period of time. There are two ways I can think of communicating this need without creating a separate API resource.

You could use an extra parameter in the GET request to tell the server that you wanted to long-poll, or to specify some sort of time-out (?timeout=5min). This isn't very RESTful since this parameter isn't really an attribute of the resource.

You could also use the HTTP If-Modified-Since header to specify a time a few minutes in the future. This would require client and server clocks to be synced up, and the server would have to be smart enough to figure out that future=long-polling.

Yes, I stole both of these ideas from the Twitter API (http://apiwiki.twitter.com/REST+API+Documentati...). I'd be interested in if there are other options.

Re: A RESTful ESME API

esjewett — Sun, 15 Feb 2009 09:01:15 -0000

Right, the fact that I'm not an expert at this stuff shows, doesn't it? :-) You and Richard are exactly right that it's "DELETE" and "PUT" instead of "DESTROY" and "UPDATE". I'll make the change.

Re: So you want to trust your workflow to the web – good luck with than plan

esjewett — Sun, 18 Jan 2009 12:29:01 -0000

These are excellent points, but it only gets at half of the equation. As I see it, the two main questions when working on my personal workflow are effectiveness and flexibility. My impression is that when people are thinking about their workflows there is far too much emphasis on the stability of the platform (which is your point, and a good one) because of an inflated estimate of the costs associated with a workflow change.

The basic question is this: Is a change to my workflow that takes X hours to execute worthwhile?

The way a lot of people think about this question is by asking "Do I have X hours to spend on this or would I rather spend it on something else?"

The question people should be asking contains another variable - the number of hours they will save overall through this change. Let's call this number of hours "Y". The question is: "Do I have X-Y hours to spend on this or would I rather spend it on something else?" When the number of hours saved (Y) becomes greater than the switching cost (X), the cost associated with a workflow change becomes negative.

I actually switch tools quite often, so my estimate of the total productivity gain for a given tool is necessarily limited by a short time horizon and my tolerance for switching costs should be correspondingly lower, but I still find that a switch is of tools is justified for a pretty small daily productivity gain (even 5 minutes saved per day makes a tool a clear winner).

If Google Reader shut down tomorrow and I had to switch to a different feed reader, would I come out ahead in productivity over the last year or two as compared to the next best solution? I have no doubt in my mind that I would. As such, I have no problem "entrusting" this part of my workflow to the web, as long as the switching costs (X) are less than the productivity gain.

I find that the "web-iness" of a tool doesn't factor much in the estimate of switching costs. The OPML export from Google Reader happens to make the switching cost very low, which makes my decision to use Google Reader very easy.

Re: kthxbai, I just deleted 99 of your twitter friends

topperge — Thu, 08 Jan 2009 15:25:29 -0000

I can do a post on a JSON request through jQuery pretty easily. You're right that I can't do it with XMLHTTPRequest and missed that point in my slumber last night.

I agree that OAuth helps the problem because it'll prompt me to agree to authenticate the site to use the different pieces of the API, but the average user is going to check all the boxes and not think. If I decide to be a malicious developer I already have the authorization to modify your account privs.

There has been some big discussions on the Twitter developer group about adding OAuth which they don't think will really solve the problems. As with anything security related its always a cat and mouse game and the standards are ever evolving. The next step in the process is going to be risk and pattern based profiling presenting people with secondary forms of authentication when they fall out of the box.

Re: kthxbai, I just deleted 99 of your twitter friends

esjewett — Thu, 08 Jan 2009 09:07:02 -0000

Looks to me like they are describing using a GET request to the API to load some JSON into the browser. I don't think this will work for POST requests, so the friend deletion probably won't work. I assume they don't use XMLHttpRequest because the cross-site request will fail, as it should.

I don't think this is really a huge deal. It probably does raise a valid concern about privacy using HTTP basic authentication on an API in general, since one could use this to access the status messages of a user with a non-public timeline. If I understand OAuth (and I've had a bad week on that front), it would help with this problem because the javascript on the non-Twitter site wouldn't have access to the proper token value to access the API. However, Twitter would have to stop allowing Basic authentication for the API entirely to avoid what we see in this example and I don't see that happening in the near future.

Re: Poll: Do You Want Moar Content?

jkuramot — Wed, 10 Dec 2008 15:28:38 -0000

That sounds like a nice way of saying "no" :) which is fine. I'm not biased either way, which is why I threw it up for a vote.

And it sounds like more work for me.

Re: Poll: Do You Want Moar Content?

esjewett — Wed, 10 Dec 2008 14:45:41 -0000

I'd just ask that you make it optional by providing a feed for full posts, a feed for Reader shared items, and a combined feed. Advertise whichever one you want, but make an option available :-)