Is There A Plurk API In Our Future?
I have been thinking about this question a lot, and had written about half a column about it, when Keith Hanson appeared in an IM window this morning. We had a very interesting conversation about it. We agree that it would be handy to have an API, for any number of reasons, but we also agreed that we were unlikely to get one any time soon. This is both a good and a bad thing.
With an official Plurk API, it would be child’s play to do what Keith is doing with almost superhuman effort now, which is writing a Plurk client, Plurker. He is having to guess, and then research, everything that Plurk is doing. It is quite a detective novel thing that Keith is doing. And things are coming along well, much to his credit.
Still, we should not expect to see Plurk release an API in the immediate future and make Keith’s job easier. For one thing, they are still making changes in the GUI in a fairly rapid manner. In order to give us what we want, the A-Team is doing a LOT of work, resulting in a lot of new functionality. I also have a theory that Plurk got released a little early, before some of the planned functionality had been coded, in order to take advantage of Twitter’s woes. The Plurk team is nothing if not smart.
And that brings up the other major reason why I don’t think we will see an API in the extremely near future. It was after Twitter released an API, and every coder on the planet threw together a Twitter client, that the problems really started. Having a large group of undisciplined calls to one’s API is much different from having a lot of pressure placed one’s Web application, in terms of controlling the load. I think that by delaying the release of an API, Plurk is quite wisely trying to control their own destiny.
We all are seeing, right before our eyes, the near-death experience of Twitter. Plurk does not want to repeat the Twitter mistakes, and we should hope that they do not. All of us that have really come to love what Plurk does want it to continue unimpaired into the future. The A-Team will know when the time is right to release an API. I don’t want to see it rushed, while they are still giving us regular functionality prizes, and especially not if is it is going to cause performance problems.
I’m KDFrawg on Plurk. If you see me, stop and say “Hi!”
July 1st, 2008 at 12:17 pm
Okay… here is where I show my ignorance… what is an API and what is its function?
July 1st, 2008 at 12:21 pm
Nicely said, I could not agree more. Plurk is, in addition to rolling out new features, still experiencing its fair share of down(ish) time. Adding a significant burden to that would be a bad idea.
July 1st, 2008 at 12:34 pm
NotAMeanGirl, an API is basically a standard library of code that Plurk would allow other people to run in their own applications. So you could develop a desktop Plurk client, for instance, that would allow you to post new plurks, add friends, etc.
July 1st, 2008 at 12:40 pm
I agree with you completely. Fools rush in. I would like to think Plurk is learning a lot from watching what is happening to twitter lately.
July 1st, 2008 at 12:45 pm
Excellent article, as always. The one thing I wish is that Plurk would learn a fast lesson from Twitter and hire someone to let everyone know what’s going on and handle questions, etc. I’ve actually written and suggested they could use a community manager (I KNOW they have to be getting tired of hearing from me by now).
I’m going to show my ignorance here, but because Keith doesn’t use the API, will it affect the Plurk resources it draws from? Will there be less risk of the program crashing? Or is it just that apps take longer and are harder to build, so there aren’t as many coming along to drain the system?
And LOL should I mention that it’s totally unfair that I don’t have either you or Keith on my IM list?
Te-ge
July 1st, 2008 at 12:48 pm
I’m just happy on Keith’s beta testers list because I buttered him up last night.
July 1st, 2008 at 1:03 pm
@Yooni Suckup! LOL
@Mike TY for explaining that to me. I feel like such a dork. Its basically an open source code then?
July 1st, 2008 at 1:51 pm
@Teeg: Mike explained API well, but in all honesty, it’s used a bit differently when talking about websites. When two websites communicate with each other, typically they setup an API to do it. It doesn’t necessarily mean open source code (but it can include open source examples), it means more like a contract for how two websites SHOULD communicate with each other. For example: Website A calls the URL /TimeLine/getUpdates at Website B. Website B should send over the appropriate response of the number of updates in the timeline.
What it means to not release this, is that if someone wants to communicate with, say, Plurk, then they’re going to have to do some serious digging and toying with the system to fully understand how to communicate with it. Essentially, I’m trying to decode how the Plurk interface works, and how to interact with it in my own client. I do this by watching, watching, watching, guessing, trying, watching watching and more watching, haha.
If Plurk would publish how to communicate with them, then it really would be trivial to do so.
SO, am I affecting Plurk’s resources at all? In short, not at all. Basically, I’m doing what your browser is doing when you view your Timeline. Saying that ‘I’m not using the API’ is just another way of saying, ‘He’s fumbling in the dark without guidance from Plurk, but he’s doing a damn good job of it’
So yeah, it’s really my main intent to do EVERYTHING that the browser does, and a little more. That ‘little more’ though, won’t tax Plurk’s system one bit. In short, Plurk won’t even know the Plurker client is being used (unless they look at the web requests my client makes, hehe).
And yes, Teeg, they take much longer and are much, much harder to develop for. But, that’s part of the fun for me. It’s also something I think Plurk is leveraging. Giving themselves a bit of a buffer while they’re getting mostly on their feet.
And Teeg, you are most certainly welcome to add me on AIM
Send me a private plurk.
@yoonamaniac: What can I say? I’m a sucker for compliments
July 1st, 2008 at 1:57 pm
@NotAMeanGirl; what the API does, to follow up on what @mike said; gives a set functions to the app programmer which allows them to easily access things inside the plurk world.
for example: function name: plurker_plurk() , app programmer would use the function as: plurklist[I]=plurker_plurk(@NotAMeanGirl[I]) , where “I” goes up by 1 in a loop and the plurker_plurk function would return all the plurks made by @NotAMeanGirl starting at I to X(X being the last/first plurk).
So using the API function call would allow for an app programmer to read all plurks which had been made by @NotAMeanGirl and display them in a list.
Again, just a simple example; I tried to made it simple to understand, but I hope not too simple
July 1st, 2008 at 2:00 pm
@Nethead: Well, even still, most websites don’t publish a chunk of source code or library for developers. They might do it in one language as an example, but largely, it’s a protocol for requests and responses. Essentially, “Here’s what you CAN do, and here’s what you can EXPECT from us”. Even if they didn’t release one drop of code, and only told us what we CAN do and EXEPCT from them, any programmer worth his salt could make the library in a couple days’ worth of work.
July 1st, 2008 at 2:02 pm
And the problem with having a public API is that if someone makes a really great plurk client, let’s say, that can automate the publishing of new plurks, you could use that to overwhelm the main sites system unless they start throttling the number of posts that can be made per minute, etc. So while Keith’s client won’t by itself cause stress problems to Plurk, that type of program could be tweaked to cause trouble. With no public API, it is easier for them to hide functionality or change it without worrying about the consequences to 3rd party tools.
July 1st, 2008 at 2:18 pm
@Mike: Most definitely agree with you there, and I think that it’s very possible to bog a site down. BUT, I disagree with the general idea of NOT providing a public API. The whole idea behind the Web 2.0 (or whatever hip trendy way of saying our web today) is the open sharing of information.
And though we’ve seen it really, really hurt Twitter, I say it’s TWITTER’s fault, not the clients, as much as I hate those that take advantage of Twitter. It’s Twitter’s fault because of the fact that Twitter doesn’t enforce well enough with their API. And they started enforcing too late in the game, imo. Now, essentially, they’re punishing their users instead of punishing the shitty clients that take advantage of them. They should be building SMART rules, not sweeping group punishments. They should punish the clients that take advantage of twitter, not the ones who make sure that they behave.
If Plurk does the same with their API, and punish the clients which do NOT follow the rules, then all the users of those craptastic clients will stop using the clients, and take care of the problem FOR Plurk. It’s a little more work up front, it takes a little more thought to implement, but it’d go a LONG way for Plurk.
July 1st, 2008 at 2:57 pm
Keith and Mike, thanks for the GREAT answers! Can I ask a couple more questions, just to make sure I’ve understood clearly? LOL If you said no, skip the end.
So an app acts like a new user…for each person who uses it? When people use Twirl with twitter, it’s like double people using the system? Or does the app disconnect the website unless the page is open? And if you use another one, like Snitter at the same time, it would multiply?
I’m guessing that aggregators actually are better? Or are they the same as far as actual stress to a site? LOL are you regretting starting to explain this?
Okay, enough questions for now. Thank you all again (including you, Mr. KDFrawg :)) I had never really thought about how an app must drain a system.
July 1st, 2008 at 3:15 pm
@Teeg: So a bad application like Twirl makes TONS of requests as opposed to what a normal user might do. That’s what I mean when I say a craptastic client that’s not respecting any sort of etiquette to the system it’s accessing.
Each app does act like a user. In theory, most people who create an application for a web resource (twitter, plurk, etc) probably won’t use the normal web interface. So, in a perfect world, those applications will respect the resource they’re using and not make an obscene amount of web calls to that resource. THUS, the resource shouldn’t even take a hit.
On the other hand, yes… if you are accessing that web resource multiple ways (Twirl, Snitter, WebPage), then yeah, you’re going to be bringing three times the traffic (that’s in a PERFECT world. With bad applications like Twirl, it’s even worse). So yeah, you’d multiply it.
What do you mean by Aggregators?
July 1st, 2008 at 3:23 pm
Keith, I meant sites that bring multiple sites together and post to their own site. Friendfeed is a good example, Facebook does it also with some of their apps, and there are several others out there that either send to or gather responses from sites.
July 1st, 2008 at 3:44 pm
Oh. I’d say those add QUITE a lot of traffic. I mean, they’re _always_ on, even when you have your computer turned off. At least with desktop clients, the web resource has a chance to ‘rest’ when you close the client, haha.
July 1st, 2008 at 3:47 pm
LOL Just realized we’re treating your comments like a Plurk conversation, KD. Hope you don’t mind.
Keith, Wow! I didn’t realize all the drain on popular applications lately. Is there a way to minimize the damage to sites, other than cut back on the number of posts allowed per minute?
July 1st, 2008 at 3:55 pm
See, that’s where I’m thinking that Web Resources need to step it up on their API. Have auditing processes that watch the clients. Watch EVERYTHING coming across the network. If a particular IP address is hammering the website, lock it down a bit. Limit THAT IP, not everyone all at once. If they’re mass sending the same message over and over or something, lock them out completely, by account. etc.
By putting effort in on the rules and auditing up front, they’d buy a lot in the long run. Like I said, as soon as someone gets locked out a couple times from their client, they’ll stop using the client, the developer will lose steam on their project, and finally it’ll be abandonware. Therefore, smart auditing and rules would cause the USERS to solve the problems themselves
July 1st, 2008 at 4:00 pm
It’s the Plurkiverse API!
KDFrawg (the Plurkiverse dewd)
July 1st, 2008 at 4:01 pm
@KDFrawg: Haha
Hope you don’t mind! This has turned into a great thread I think 
July 1st, 2008 at 4:02 pm
I always feel like such a dunce whenever anyone talks about API, because I don’t understand what an API is. It has been explained to me SEVERAL TIMES but I just don’t get it. But, erm, it sounds like a good thing so I hope plurk gets one!
July 1st, 2008 at 4:11 pm
If I’m understanding it right, @calinazaret, API is basically like a shortcut.
Instead of having to search for an unlisted number, the API is like having speed dial on your phone and calling someone.
Is that the (very) general idea, guys? Or am I totally off base?
LOL Loving this discussion. How often does this happen on a website?
July 1st, 2008 at 4:21 pm
@calinazaret: It’s been explained pretty well throughout the comments, I’d say, BUT Teeg has explained it pretty succinctly.
Another version: an API could be compared to your microwave (bare with me
). You, the user of the microwave could be considered the Programmer, and the Microwave the system you want to work with. You, as the programmer, don’t care HOW the microwave does what it does. You just know that you interface with the microwave by putting food in, pressing the buttons, hitting start, and getting the result.
The buttons, then, are essentially your API. After you send the appropriate button presses to the microwave, it does it’s thing and spits it out.
As a programmer, the API is your buttons
The Microwave is your system that does work for you (in Plurk’s case, giving plurks, responses, responding, etc). And the food is the input/output of the system.
Does that make sense?
July 1st, 2008 at 4:22 pm
teeg thinks her explanation is simplier
July 1st, 2008 at 4:29 pm
Hahaha. I agree with you Teeg
But… the Microwave PERFECTLY describes the aspects of an API, haha.
July 1st, 2008 at 4:35 pm
@All -
Plurk is like a person. The Plurk API will give you a panel of buttons to push to make it do something, just like you know what buttons to push to make your SO react in one way or another. Except that the Plurk API will come with documentation, and your SO doesn’t.
KDFrawg (the Plurkiverse dewd)
July 1st, 2008 at 5:28 pm
What a great post, and a fantastic comments thread.
An explanation that helps understand Plurk, a site that I seem to be using more everyday.
And yes, looks very much like a Plurk conversation
Thanks,
Allan
July 1st, 2008 at 5:59 pm
So, if this were a real plurk conversation we would all start talking about what is for dinner since microwaves were just mentioned
One thing to remember about aggregators is they are normally subscribed to feeds which help lighten the load on the main servers. Instead of constantly having everybody hitting the plurk servers to get updates, the aggregators hit them to do a pull and then server that information to each user looking for that particular feed. So if 5 people are subscribed to my plurk feed (beagooddad) in Google Reader, than instead of each of them hitting plurk to get the feed, Google Reader hits it one time and delivers it to all 5 users when they access their feed reader.
July 1st, 2008 at 6:13 pm
@Mike: Hm. Isn’t Google Reader hitting a feed every few minutes though?
It depends on how the server is rendering the feed. Is it live rendering? Or are they being smart about it and pumping out a static XML file only when there are updates on someone’s feed, thus saving trips to the database and offloading the traffic to a static content server (much fastah)…
Am I right?
July 1st, 2008 at 6:20 pm
Do people really only use the aggregators without having the other sites open?
LOL Now I have a new question. If I have several tabs of the same site, is that acting like multiple users? It’s rather common for me to have a couple Twitters and around 6 (and occasionally as many as 12) Plurk tabs going…especially if I’m involved in several real conversations on there, along with (uh, I’m embarrassed to say how many) a bunch of other aggregators, SM sites, etc.
*nervously biting her lip and hoping she isn’t hurting the sites she loves*
July 1st, 2008 at 6:29 pm
If you have multiple pages of your profile open, then yes, it’s hitting Plurk multiple times every 15 seconds or so.
If you’re using multiple ways of accessing the site, then yeah, it’s hitting plurk multiple times.
But you don’t need to worry really. I’ve talked about this before on this blog I think, but Plurk’s calls to their webservice are SUPER light and efficient.
I wouldn’t worry about little ole you doing the site any harm
July 1st, 2008 at 7:02 pm
Phew, thanks Keith! You relieved my mind.
July 1st, 2008 at 8:03 pm
Keith, I always thought the XML feed files were always static and updated as a push by the server when there is a change but I’ve never really looked into that at all so I’m probably wrong.
July 1st, 2008 at 8:34 pm
@Mike: Well, that’s the best way of implementing it, but a developer can implement showing XML any which way they’d like, really
In my last job we had an XML feed that was hit every so often, so we just generated it on the fly every time it was called. Dumb, but it got the job done.
July 1st, 2008 at 8:57 pm
@Mike, @Keith, I think some RSS Readers are able to fetch their feeds either automatically in a certain interval, or manually (by the user). Most readers will fetch the latest feeds everytime they are opened.
@Keith, I just send you a friend request at Plurk. I am currently buiding Plurk web-app down at Plurkerati.com, it could be good to talk about implementation on Plurk API that you are using.
July 1st, 2008 at 9:11 pm
Feel free to add me on AIM. I just completely 100% fleshed out my API to work EXACTLY like Plurk works. Wouldn’t mind talking to someone else developing against this closed up beast either
Just sent you a private plurk with my AIM/GTalk info.
July 1st, 2008 at 10:36 pm
Great article, man! I think you’ve pretty much nailed the API issue on the head. They’re not ready to release it yet, nor should they. And, as you said, they really need to take a cue or twelve from twitter in how they move forward. I think you and I agree that it’s better to wait for quality then get crap pushed out the door in a hurry.
BTW, happy to see you installed the Subscribe to Comments plugin. If it was there before and I missed it, never mind.
July 1st, 2008 at 10:39 pm
LOL! It was always there. I really like it. I’m pondering putting in Comment love, too.
July 2nd, 2008 at 7:18 am
Well, crap. I missed it this whole time. No big. Happy to know about it now.
July 2nd, 2008 at 10:30 am
We will release an API, the reason why we don’t do it now is because it’s a challenge to make it scale - > and we don’t want to release something that will be a burden for the general service.
Using our internal calls is a bit risky as we may optimize and change things in the future - and we will do this with little warning as these calls are internal calls. So any developer that uses internal calls must know this
But anyway, very interesting blog post.
amix
July 2nd, 2008 at 10:53 am
Wow! Hey Amix!
Just a note, anyone taking the time to reverse engineer your current API is, I’m sure, aware of the nature of such a task. And thus, I myself am prepared to fix my shit when you change yours
Exciting times, sir! Exciting times!
Cant’ wait for the API Amix.
I’m wondering… how are you guys planning on handling the policing of your API? I’d love to see some intelligent rules, not just wide sweeping ones
July 2nd, 2008 at 10:54 am
@amix -
Thanks very much for the clarification. It is always good to hear from you. The reason that you state is the very one which we have all agreed was the major reason for not releasing the API. More importantly, none of us want an API released if it is going to hurt the web-based service. You guys are being very responsible and careful not to let the demand overwhelm you, unlike some other sites we could name.
I think it is very cool that you stopped by to comment, and that you all are trying so hard to make Plurk even better, and that you will actually communicate meaningfully with us. Word for the A-Team is much better than rumors. We really appreciate it.
The A-Team rocks!
KDFrawg (the Plurkiverse dewd)
July 2nd, 2008 at 11:09 am
It’s nice to see someone from the A-Team actually reply to such as post. It’s definitely proof of character for the people who are behind Plurk.
Keep up the good work fellas! (this goes for KDFrawg and KeithHanson too)
July 2nd, 2008 at 2:33 pm
[...] cares about what we think. I was reminded of that again this morning when @amix posted a comment on yesterdays Plurkiverse post. He didn’t have to do that. Heck, I don’t even know how he knew that there was a post [...]
July 3rd, 2008 at 3:49 pm
[...] “We will release an API, the reason why we don’t do it now is because it’s a challenge to make it scale - > and we don’t want to release something that will be a burden for the general service.” – Amix’s comment on PlurkiVerse [...]