- Currently Listening to:
- Iron & Wine — Lovesong Of The Buzzard
Daniel Sandler is experimenting with using twitter for comments, and makes some very good points about comments on the web in the process. Essentially, he pulls in the content of any tweet that references his post’s full URL, TinyURL, or even just the TinyURL hash. This has the very nice effect of forcing people who want to comment on his post to own their words. Their comments will be public to their own audience, and so are more likely to be constructive and civil.
Tying your tweet to a particular page online is awkward though, due to Twitter’s 140-character limit. URLs were designed to be expressive, but not necessarily space-efficient (compare them to DOI or ISBN codes). Twitter’s recent rise has driven the increased use of URL-shortening services like TinyURL and bit.ly, which were originally designed because of the limitations of email clients that weren’t able to correctly break up an URL that was wider than the 80-character wide text columns used at the time.
We seem to have replaced one limitation with another though. By feeding all URLs through minimisation services, readers lose all context about the page they are about to open — is it a video? What domain is it on? Have I visited it before? There are some links that I would be disinclined to click on when using my iPhone, but with minimised URLs, you don’t know what you’ve got until it begins to load in. Plus, there’s the nightmare scenario that the URL service dies, and since their databases are kept private, all that information is lost.
I think URL shortening services could be obviated if Twitter started treating URLs a little differently. There are two main audiences for twitter tweets: mobile phone users who receive tweets as SMS messages (this is the original reason why twitter has 140-character limits), and users who visit the twitter website, or use one of the myriad desktop and smartphone applications to keep up with tweets. These users are not concerned about the character limit in the same way. I would expect this group of people to be growing faster than those who get tweets via SMS.
Ideally, Twitter would disregard URL content as part of the character limit. If you think about it, the URL http://tinyurl.com/cxt59m (this page) conveys almost no information whatsoever. It could as easily be replaced with some single-character replacement in SMS messages (whose users are much less likely to actually follow links than web/applications users anyway). [On further reflection, it is clear that this wouldn't work as I imagined, as the target URL for these single character links would still need to be encoded somewhere as part of the message.]
On the web, and in applications, URLs shouldn’t need to be minimised at all. Twitter clients could truncate URLs for display, but all the URL content should stay available to be used by those clients that want it.
- Currently Listening to:
- Eddie Vedder — Society
Twitter has really taken off in the last few weeks. If you haven’t signed up yet, and are sick of hearing about it, I sympathise. I didn’t understand what the point was at all until I signed up, originally just so that I could follow a few interesting people better than I could using RSS. Eventually, you’ll see a conversation going on and want to join in.
From a web architecture point of view, Twitter is particularly interesting because it is, to my memory, the first web 2.0-ey application that doesn’t really need a website. They’ve done such a great job with their API and backend that there are dozens of excellent applications and plugins for just about every publishing platform. I read and post from a bunch of applications — Tweetie on my iPhone, and Lounge and Tweetdeck on my laptop — and very rarely actually visit the Twitter website.
I guess this is a matter of partly good timing (now that smartphones are common), and partly that tweets are perfect iPhone-sized data.
- Public APIs availability - uptime and down time - slow performance
- IB API
- ProgrammableWeb - Mashups, APIs, and the Web as Platform
- millennium | Google Chrome Extensions
It became clear that we’d have to fix this before Firefox could reach 1.0, so I put together an extension manager that offered a less hacky install/uninstall path and more importantly added versioning. Given the lack of stable APIs, the system would simply disable extensions not advertised as being compatible with the current version of the browser. This meant developers would have to certify their extension with every new version of Firefox. It wasn’t perfect and was somewhat cumbersome, but it worked, and didn’t require us to freeze a bunch of APIs which we most certainly would have botched if forced to do it in haste.
- Seeking to Understand » Blog Archive » Birth of a Platform
They’ve been slowly training us developers to stick with the documented stuff and use their higher level APIs. They want us to accept their abstractions and work within them. This is usually rationalized under the guise of safety, compatibility, and quality control. Those are fine and acceptable reasons by themselves, but what if there’s another purpose lurking behind the curtain?
I think there’s a chance that Apple is slowly building Objective-C into a managed environment similar to Java/.NET. At some point in the future they could define an Objective-C HD (or whatever :P) that no longer maintains total compatibility with C.
- Diego Torres Milano's blog: Android: Playing with Intents
From Google documentation: “An Intent is a simple message object that represents an ”intention” to do something. For example, if your application wants to display a web page, it expresses its “Intent” to view the URI by creating an Intent instance and handing it off to the system. The system locates some other piece of code (in this case, the Browser) that knows how to handle that Intent, and runs it. Intents can also be used to broadcast interesting events (such as a notification) system-wide.”
An intent is an abstract description of an operation to be performed. It can be used with startActivity to launch an Activity, broadcastIntent to send it to any interested IntentReceiver components, and startService(Intent, Bundle) or bindService(Intent, ServiceConnection, int) to communicate with a background Service.
- Intridea Blog: REST isn't what you think it is, and that's OK
The misconception lies in the fact that, as tends to happen, the popular definition of a technical term has come to mean something entirely different from its original meaning. To most people, being RESTful means a few things:
Well-defined URIs that “represent” some kind of resource, such as “/posts” on a blog representing the blog posts.
HTTP methods being used as verbs to perform actions on that resource (i.e. GET for read operations and POST for write operations).
The ability to access multiple format representations of the same data (i.e. both a JSON and an XML representation of a blog post).
- Marco.org - Twitter is not public infrastructure
Is Twitter’s rate-limiting the only factor giving you pause about building a business that depends on Twitter? Maybe I’m a cynic, or maybe it’s the programmer in me trying to enumerate all possible failure cases, but I don’t feel comfortable trusting my business’ success to a private third party over whom I have zero control.
- /dev/why!?! - /dev/why!?! - Its all about the framework…
So, if you will indulge my claim that backwards compatibility is hard (even absent the private API issue) it is pretty easy to see why supporting other runtimes is ceding a lot of control to a 3rd party. Imagine if 10% of the apps on iPhone came from Flash. If that was the case, then ensuring Flash didn’t break release to release would be a big deal, much bigger than any other compatibility issues. Since Apple doesn’t have access to Flash CS5’s runtime library code or compiler frontend, they might be put in a position where they would need to coordinate with Adobe to resolve those issues. Shipping a new release where Apple breaks any specific application, even a top seller, is not an issue if the release is compelling, most apps work, and Apple has the option of working with the vendor to help them fix their app. Shipping a release where they break a large percentage of apps is not generally an option. Letting any of these secondary runtimes develop a significant base of applications i
- [webkit-dev] Announcing WebKit2
Given what proportion of overall maintenance work on WebKit I done by
Apple, I don't think anyone is entitled to veto us adding a new API
layer. I also recall that when the Chromium API layer was added, no
one asked permission, you just let us know that it was coming. Which
is fine - API layers are pretty low cost, and I hope no one would
argue against a major contributor including theirs. What's more, this
is really a parallel version of existing well-maintained API layers. I
do not like the implication that Apple should have to ask permission
for what we do with the WebKit API on Mac OS X. We do not ask the Qt
or Gtk developers to explain all their API choices.
- Hacker News | Getting away from the frenzied rhetoric, my opinion is that what Apple really wa...
Getting away from the frenzied rhetoric, my opinion is that what Apple really wants to prevent is people releasing multi-platform compilers. So taking Flash as just one example, if I can build one app and the compiler can make me an iPhone executable, an Android executable, and so forth, Apple don't want that.
In my experience so far with such "cross platform compatibility layers," they always produce results that water down each platform's individual strengths and differentiations. And of course, instead of the developer being locked into the phone platform, they are locked into the compatibility layer's platform.
Adobe's Flash compiler is a classic maneuver to "commoditize your complements," as Joel put it so well. Apple don't want to be commoditized, especially if it means having apps that don't take advantage of the iPhone's strengths.
- YouTube - Bertrand Serlet on using Apple's private API's
- OpenFeint - The coolest thing since sliced awesome.
OpenFeint is an easy and free way to get more out of your games!Think XBOX Live meets Facebook for the iPhone with hundreds of games and millions of players.
- Twitter with a Brain — Shotton.com
- Server-side Integration of GFC - Google Friend Connect APIs - Google Code
In addition to letting you run social gadgets on your website and display social information using JavaScript, Friend Connect can also be integrated with existing server-side code. One type of integration possible is with an existing login system, letting anyone with a Friend Connect account log into your website without having to complete a registration process.
Follow me on twitter
Recently shared