<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0"><channel><title>mikepk - Latest Comments</title><link xmlns="http://www.w3.org/2005/Atom" rel="http://api.friendfeed.com/2008/03#sup" href="http://disqus.com/sup/all.sup#forumcomments-a1395df0" type="application/json"/><link>http://mikepk.disqus.com/</link><description></description><language>en</language><lastBuildDate>Mon, 26 Oct 2009 18:12:35 -0000</lastBuildDate><item><title>Re: The Long Game</title><link>http://mikepk.com/2009/10/the-long-game/#comment-21061469</link><description>Oh, I certainly agree that there will be no single feature, but when the big developers leave the platform behind, it makes a certain class of user (especially the kind that evangelize in the press, to their friends, etc).&lt;br&gt;&lt;br&gt;As for Wave, I know it's a long way off (I've been playing with it for a while and still only /kinda/ get it). But what if instead of calling it wave, Google had a good way to integrate it into the general messaging platform, as a sort of "Group MMS on steroids with a timeline", you could see the value. You could also see the potential to make the iPhone and it's one-to-one style of communication, clunky "push" notices, look very dated. I don't think it'll be any one feature, like you said, but a lot of devices that are "good enough" and better tuned to a specific niche. I think the same goes for features: the iPhone, despite being quite feature-poor relative to modern smartphones, is still seen as "cutting edge". That image can't last forever, as new devices and entrants constantly take away another badge from the iPhone. There used to be a lot of unique features that added up to the iPhone "feeling" advanced to a new user. Multi-touch, large screen, thin device, long battery life, (mediocre) GPS, but many devices trump in not one, but MANY categories now. The HTC Dragon/Pro.Three looks to dwarf in many categories, whereas smaller devices like the Pixi and Droid scream past in others. There will be no one featureset that pushes it out, but the slow realization among consumers that an Apple is "okay" at a lot of things, but no longer the best at anything. Once that happens, it's very difficult to change the opinion. Look at the iPod classics...even iTunes. Both have been out-teched or out-features by one competitor or another, and while it doesn't directly dethrone them, it reminds the consumer that choice is a good thing, and that blindly buying the next generation of Apple product might be a losing bet.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">calciphus</dc:creator><pubDate>Mon, 26 Oct 2009 18:12:35 -0000</pubDate></item><item><title>Re: The Long Game</title><link>http://mikepk.com/2009/10/the-long-game/#comment-21060072</link><description>That's a good point, I forgot that particular parallel. :) I think Google needs to be careful with rolling out advanced features like you describe. Even the tech elite can't quite figure out Google Wave at the moment, let alone mass consumers. Remember that all of the features of the iphone existed before the iphone appeared (browsers, touchscreens, email, etc...)  It was the experience that tied it all together that made the iphone something different. I don't think features are going to drive the platform as much as cost. When Android handsets number in the hundreds of millions because every carrier subsidized free phone runs a 'smart phone' OS, that's when we'll see this strategy really bear fruit. I think it's then that we'll likely see the 'killer app' that you describe.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">mikepk</dc:creator><pubDate>Mon, 26 Oct 2009 17:43:39 -0000</pubDate></item><item><title>Re: The Long Game</title><link>http://mikepk.com/2009/10/the-long-game/#comment-21058829</link><description>One particularly interesting parallel, too, is that the current rivalry sprung out of what was once a mutually beneficial relationship. The original Macintosh shipped with quite a bit of Microsoft code on it, most notably the really tough stuff (floating point calculator, for example).&lt;br&gt;&lt;br&gt;Part of what made the iPhone an initial success was Google's status as preferred software vendor. Google maps was a huge success (despite being available for every other platform already), and seemingly everyone wanted to be the next Google Maps for the iPhone. However, once Google stops pulling punches and actually leaves the iPhone behind (as it did with Street View, with the iPhone being the last to get it, not the first), iPhone users will no longer feel special - they'll begin to feel the constraints of a closed platform. &lt;br&gt;&lt;br&gt;What happens when every new Android phone comes integrated with Google Voice? Visual voicemail will be a thing of the past, compared to the Voicemail-to-text option on the G2-generation. Deep, OS-level integration with Google Wave will beat the pants off of the three-years-too-late MMS on the iPhone. And what happens when Google (or some enterprising startup) comes out with the next must-have feature to beat, like (say) remote DVR integration, full remote media library access, etc? The kind of stuff carriers and media companies fear, but users crave? Suddenly the gilded cage of the closed iPhone app world looks a lot less appealing.&lt;br&gt;&lt;br&gt;Apple has a history of burning its best partners. Microsoft, Adobe, Google, all eventually split off and become rivals. It may be Apple's internal politics, it may just be the way relationships go, but it is always Apple's user base that suffers as a result.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">calciphus</dc:creator><pubDate>Mon, 26 Oct 2009 17:19:49 -0000</pubDate></item><item><title>Re: Hackers and Painters in Seattle</title><link>http://mikepk.com/2009/08/hackers-and-painters-in-seattle/#comment-15486477</link><description>I thought your presentation was great. At one point I was thinking about if we begin to augment ourselves by hacking our own experiences and perceptions, could we get to a point where we're not only expanding space (as in information space) but time (as in processing time). Being that our perception of time is somewhat plastic already, with augmented processing, could we make a minute feel like an hour perceptually? Imagine interstellar travel where thousands of years are perceived as a week? Anyway really neat ideas!</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">mikepk</dc:creator><pubDate>Thu, 27 Aug 2009 16:06:54 -0000</pubDate></item><item><title>Re: Hackers and Painters in Seattle</title><link>http://mikepk.com/2009/08/hackers-and-painters-in-seattle/#comment-15429498</link><description>Thanks for the kind words. It was a wonderful experience to attend my second Gnomedex. Great to see you there, too!</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">caseorganic</dc:creator><pubDate>Wed, 26 Aug 2009 13:38:45 -0000</pubDate></item><item><title>Re: It&amp;#8217;s tough to make predictions, especially about the future</title><link>http://mikepk.com/2009/06/its-tough-to-make-predictions-especially-about-the-future/#comment-12398512</link><description>Thanks James, I'm still a fan of your ideas! It was great working with you and I'm glad we got the chance to meet in person. I still think feeds are an important part of the future of news and information on the web, people just didn't seem ready to graze yet. :) I hope we stay in touch in the future.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">mikepk</dc:creator><pubDate>Thu, 09 Jul 2009 15:14:58 -0000</pubDate></item><item><title>Re: It&amp;#8217;s tough to make predictions, especially about the future</title><link>http://mikepk.com/2009/06/its-tough-to-make-predictions-especially-about-the-future/#comment-12395503</link><description>Mike, I'm a bit late in hearing this news and just wanted to wish you the best of luck in future. It was great meeting you during my trip to Boston and I know that whatever you do in future you'll make a success of it.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">James Corbett</dc:creator><pubDate>Thu, 09 Jul 2009 14:37:00 -0000</pubDate></item><item><title>Re: It&amp;#8217;s tough to make predictions, especially about the future</title><link>http://mikepk.com/2009/06/its-tough-to-make-predictions-especially-about-the-future/#comment-11702412</link><description>You've been a terrific supporter and I've always appreciated your counsel and feedback regarding Grazr. I feel lucky that we had such passionate and engaged users. I really am sorry that the news radars will stop working, I know how hard you worked on them.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">mikepk</dc:creator><pubDate>Wed, 24 Jun 2009 17:54:31 -0000</pubDate></item><item><title>Re: It&amp;#8217;s tough to make predictions, especially about the future</title><link>http://mikepk.com/2009/06/its-tough-to-make-predictions-especially-about-the-future/#comment-11701255</link><description>Thanks David, I'll look you up if ever I'm in London!</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">mikepk</dc:creator><pubDate>Wed, 24 Jun 2009 17:38:56 -0000</pubDate></item><item><title>Re: It&amp;#8217;s tough to make predictions, especially about the future</title><link>http://mikepk.com/2009/06/its-tough-to-make-predictions-especially-about-the-future/#comment-11696271</link><description>Dear Mike,&lt;br&gt;&lt;br&gt;I was shattered reading the news about Grazr. I remember I started playing with the widget in its early days, using it to embed stuff relevant to the topics I blogged about. When you took Grazr to the next level by implementing GrazrScript, I gratefully followed along. I too remember long sessions chatting with you about the potential of Grazr. All of the RSS news radars I built since are in fact a showcase of the genius that you are.&lt;br&gt;&lt;br&gt;There's a kind of void now, because in this stage I'm not aware of other tools that come close to what Grazr offered. Enough of that sad side of the story.&lt;br&gt;&lt;br&gt;Mike, there's a bright future ahead of you. I hope you will find a new passion that enamors you as much as Grazr did. &lt;br&gt;My sincere best wishes for you and your dear ones.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Marjolein Hoekstra</dc:creator><pubDate>Wed, 24 Jun 2009 15:45:06 -0000</pubDate></item><item><title>Re: It&amp;#8217;s tough to make predictions, especially about the future</title><link>http://mikepk.com/2009/06/its-tough-to-make-predictions-especially-about-the-future/#comment-11695586</link><description>Hi Mike. Very kind of you to mention me. I still think Grazr is a terrific piece of work, even without the soon to be dropped extra facilities. I wish you well and, if I'm ever in your neck of the woods, I'll buy you a meal. Of course, if you ever come to London (UK), be sure to let me know you're coming.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">David Tebbutt</dc:creator><pubDate>Wed, 24 Jun 2009 15:31:16 -0000</pubDate></item><item><title>Re: It&amp;#8217;s tough to make predictions, especially about the future</title><link>http://mikepk.com/2009/06/its-tough-to-make-predictions-especially-about-the-future/#comment-11692389</link><description>Thank Fred, I really appreciate it.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">mikepk</dc:creator><pubDate>Wed, 24 Jun 2009 14:33:29 -0000</pubDate></item><item><title>Re: It&amp;#8217;s tough to make predictions, especially about the future</title><link>http://mikepk.com/2009/06/its-tough-to-make-predictions-especially-about-the-future/#comment-11692275</link><description>Mike,&lt;br&gt;&lt;br&gt;I want to thank you SO MUCH for your EXCELLENT support during the past three years I was a user of &lt;a href="http://Grazr.com" rel="nofollow"&gt;Grazr.com&lt;/a&gt;. &lt;br&gt;I wish you lots of succes with whatever the future may bring to you.&lt;br&gt;There is one thing I'm 100% sure of. I will keep in touch with you.&lt;br&gt;&lt;br&gt;N.B. By the way, I will stay a user as long as &lt;a href="http://Grazr.com" rel="nofollow"&gt;Grazr.com&lt;/a&gt; lasts.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">fzelders</dc:creator><pubDate>Wed, 24 Jun 2009 14:32:00 -0000</pubDate></item><item><title>Re: Where&amp;#8217;s the Web in &amp;#8220;Real Time Web&amp;#8221;?</title><link>http://mikepk.com/2009/04/wheres-the-web-in-real-time-web/#comment-8820953</link><description>Phil, interesting tech I'll take a look. With the caveat that I haven't looked very deeply at it, in terms of infrastructure, I don't think liberator gives us the whole package. Liberator seems strongly suited for broadcast to endpoints of the content network. I could envision industrial strength comet servers for content distribution, but then an alternate internal distributed update mechanism I think could be done with more direct, application specific, protocols. What I'm exploring now is more of the idea of a RTW stack where the top level protocol is embedded in the content payload along with authorization. Basically make the updates and keys be transport agnostic. This gives you a lot of interesting abilities, like for not-so-real time updates you might use something like email as a transport for bulk messages. This would allow utilizing existing distributed infrastructure and addressing, and then possibly having member machines move the content along on whatever transport makes the most sense (XMPP, comet to the client etc...). It could also act as a strong bootstrap, rather than force the network to adapt to the new requirements, utilize existing infrastructure even if it's not perfect. It's just the start of an idea so I'm still exploring the ramifications.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">mikepk</dc:creator><pubDate>Wed, 29 Apr 2009 15:08:09 -0000</pubDate></item><item><title>Re: Where&amp;#8217;s the Web in &amp;#8220;Real Time Web&amp;#8221;?</title><link>http://mikepk.com/2009/04/wheres-the-web-in-real-time-web/#comment-8818455</link><description>Ok, I'm a bit late responding to this article. I bookmarked it a while back and just got around to reading over it. I a software engineer working for a company who have components that facilitate the distribution of data across the web in real-time. I’m hopeful that we have the real-time web silver bullet. The section of our website that details streaming push server is here: &lt;a href="http://www.caplin.com/caplinplatform/?curart_id=36" rel="nofollow"&gt;http://www.caplin.com/caplinplatform/?curart_id=36&lt;/a&gt;&lt;br&gt;&lt;br&gt;The server is a highly scalable comet server (Liberator) that supports thousands of concurrent connections, manages connection problems, load-balancing, clustering (basically, it's highly scalable) and a whole host of other features that I think are exactly what the real-time web need. The really good news is that there is a free version available: &lt;a href="http://www.freeliberator.com" rel="nofollow"&gt;http://www.freeliberator.com&lt;/a&gt;&lt;br&gt;&lt;br&gt;I'm presently trying to pushing to encourage people to use our components in areas other than the financial sector since the Liberator is an excellent piece of kit that could be put to so many other uses. It can be used to distribute real-time updates across the Internet to a number of clients (we have APIs for Java, .NET, JavaScript/Ajax). Obviously the standard clients are web pages, .NET Web Form apps and Java applications but this doesn’t have to be the case. A web page example that I really like isthe Twitter website; they’ve experienced numerous problems and even today I saw the fail whale due to high load. By using Liberator and SL4B (the JavaScript API) there would be less frantic hitting of F5 to reload the page putting strain on the Twitter servers, updates would simply be pushed to clients as soon as they become available. Liberator also caches content taking additional strain from the Twitter servers.&lt;br&gt;&lt;br&gt;I recently wrote a post about What is the Real-Time web which I think is relevant here: &lt;a href="http://blog.caplin.com/2009/04/20/what-is-the-real-time-web/" rel="nofollow"&gt;http://blog.caplin.com/2009/04/20/what-is-the-r...&lt;/a&gt;&lt;br&gt;&lt;br&gt;Has anybody tried out Free Liberator? Does anybody think that this could be the silver bullet for the real-time web? If no, what is it missing?</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Phil Leggetter</dc:creator><pubDate>Wed, 29 Apr 2009 13:54:59 -0000</pubDate></item><item><title>Re: Cool MacBook X-Ray</title><link>http://mikepk.com/2008/11/cool-macbook-x-ray/#comment-8336073</link><description>Same here. I've always been fascinated at xray images of gadgets. But not of the human anatomy, mind you. :)</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">filmless x-ray</dc:creator><pubDate>Sat, 18 Apr 2009 16:02:07 -0000</pubDate></item><item><title>Re: Where&amp;#8217;s the Web in &amp;#8220;Real Time Web&amp;#8221;?</title><link>http://mikepk.com/2009/04/wheres-the-web-in-real-time-web/#comment-8273375</link><description>Bram, XML is what we have now. Its primary problem (with regards to real time) is that agents have to continuously poll to find out if there's anything new to consume. It's inefficient and wasteful use of computing resources, especially if you intend to track more than a handful of sources. For any significant number of sources a polling paradigm just won't scale (and keep near-real time data). Imagine a long-tail of several thousand blogs that you want to filter for content but be able to get the data in near real time. Even Google, with it's massive resources, can only promise feed updates (for google reader) in about a 2 hour window. That's not good enough (IMHO) to be called real time.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">mikepk</dc:creator><pubDate>Thu, 16 Apr 2009 16:56:27 -0000</pubDate></item><item><title>Re: Where&amp;#8217;s the Web in &amp;#8220;Real Time Web&amp;#8221;?</title><link>http://mikepk.com/2009/04/wheres-the-web-in-real-time-web/#comment-8217309</link><description>“Ping networks, XMPP, update streams, FriendFeed’s SUP protocol, all try to improve update efficiencies but all seem to suffer from specific shortcomings.”&lt;br&gt;&lt;br&gt;What about using technologies like XML to deliver information?&lt;br&gt;&lt;br&gt;As someone who uses a Social Intelligence Dashboard to consume and filter a large number of content sources (of varying timescale: short ones like Twitter, and long ones like blog posts), RSS or ATOM seems to me like an easy and near-real time way to do it.&lt;br&gt;&lt;br&gt;But this carries two inherent limitation: 1) RSS, while universal, isn’t rich. 2) Pass these files through any third party filtering and splicing service (like Yahoo!Pipes, PostRank, etc.) and the latency increases.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">brampitoyo</dc:creator><pubDate>Tue, 14 Apr 2009 22:24:23 -0000</pubDate></item><item><title>Re: RSS Bankrupt? We&amp;#8217;re in a new world</title><link>http://mikepk.com/2009/01/rss-bankrupt-were-in-a-new-world/#comment-5569463</link><description>Does it go from blog to FriendFeed?</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">mikepk</dc:creator><pubDate>Tue, 27 Jan 2009 00:21:47 -0000</pubDate></item><item><title>Re: Why does Twitter owe you API access?</title><link>http://mikepk.com/2009/01/why-does-twitter-owe-you-api-access/#comment-5490152</link><description>Of course, that's the tradeoff. Twitter gives you access to their social graph, rabid engaged users, nearing mainstream market penetration, and accelerating growth. You either find a way to play their game, with their rules, or you leave it. Only you can decide if access to those traits is valuable enough to live with their restrictions as well as the uncertainty that they can shut you off at any moment. As others have said before, eventually a federated system will likely supplant Twitter, but we're a long way from there.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">mikepk</dc:creator><pubDate>Fri, 23 Jan 2009 02:28:28 -0000</pubDate></item><item><title>Re: Why does Twitter owe you API access?</title><link>http://mikepk.com/2009/01/why-does-twitter-owe-you-api-access/#comment-5490094</link><description>I think we have to agree to disagree then. :) Most of these third party applications require a social graph and enough active participation to make them useful. In essence, they're not really useful without Twitter as a foundation. You can argue that there are other services that are technically equivalent. Unfortunately, while they're technically equivalent, they do not have the critical mass that Twitter does. They don't command the same population of users or engagement. That's the power that Twitter has, they have the users and community. &lt;br&gt;&lt;br&gt;The problem with monetizing the API access is that it requires a *lot* of work to do from Twitter's standpoint. They have limited resources (as all startups do) which means they have to pick and choose what they want to work on and try to utilize that effort to greatest effect, to get the most "bang for the buck". It's not that they couldn't generate some money from the API, it's just that monetizing the API means commiting to service level guarantees, building out scalable architecture, reworking / rewriting their existing API, all while not disrupting their current growth pattern (and not allowing too much data to "leak out", since their value is their community). &lt;br&gt;&lt;br&gt;As a last point, it's also not the kind of business that's a "homerun". VC backed firms are structured to go for the absolute biggest return possible, to be the one in ten ventures that generates the actual returns for a VC fund. I just don't see API monetization as in this class of business model.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">mikepk</dc:creator><pubDate>Fri, 23 Jan 2009 02:24:13 -0000</pubDate></item><item><title>Re: Why does Twitter owe you API access?</title><link>http://mikepk.com/2009/01/why-does-twitter-owe-you-api-access/#comment-5455934</link><description>Twitter doesn't owe us anything.  However, we don't have to build or send users to Twitter if we can't build our business on the service.  It's that simple.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">jessestay</dc:creator><pubDate>Wed, 21 Jan 2009 23:47:35 -0000</pubDate></item><item><title>Re: Why does Twitter owe you API access?</title><link>http://mikepk.com/2009/01/why-does-twitter-owe-you-api-access/#comment-5455925</link><description>I totally disagree with the idea that the third party services need Twitter more than Twitter needs them. There are a lot of competitors to Twitter now, and it probably wouldn't be too much work to retarget those third party apps to point at those competitors, instead. If Twitter alienates its ecosystem, its competitors would be glad to support them instead.&lt;br&gt;&lt;br&gt;If this has something to do with monetization, though, why deny that fact to Jesse Stay, or any of the other developers building on Twitter's platform? Pretty much any reasoning suggested to Twitter seems to come back with a "nope, that's not why" answer. This isn't a game of 20 Questions, this is business. And when things happen in an irrational manner, business gets bad.&lt;br&gt;&lt;br&gt;I hope that Twitter announces its reasoning for why they aren't looking to monetize this, or otherwise use it to their advantage. And soon. Because otherwise, they'll chase away the apps that made Twitter worth using, and when those apps go, the users will follow.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">coldacid</dc:creator><pubDate>Wed, 21 Jan 2009 23:47:07 -0000</pubDate></item><item><title>Re: RSS Bankrupt? We&amp;#8217;re in a new world</title><link>http://mikepk.com/2009/01/rss-bankrupt-were-in-a-new-world/#comment-5161533</link><description>Hey Mike. I know some people really like the way Google Reader is now. I like to analogize it to the newspaper. There are the select few that decide they want to read every article, the whole paper, from A to Z as it were. It's not wrong to read that way, but it is the minority. Feed readers enforce that mental model. Most people scan the paper looking for headlines that catch their eye. They only read the things they might find interesting. Again, it's not the "right" way to read, but it does seem to match the larger population. If you increase the volume of sources, this natural human tendency to scan/filter allows you to process much greater amounts of information.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">mikepk</dc:creator><pubDate>Fri, 16 Jan 2009 03:58:05 -0000</pubDate></item><item><title>Re: RSS Bankrupt? We&amp;#8217;re in a new world</title><link>http://mikepk.com/2009/01/rss-bankrupt-were-in-a-new-world/#comment-5161527</link><description>Also in regards to Grazr, don't worry too much about reviewing it. We built the service as engineers and "feed nerds". We built *waaay* too much technology, and tried to make it too powerful. Case in point, Grazr isn't really a "firefox sidebar" reader, it's a small piece of code that can act that way, or as a widget to publish on your blog, or as a full stand alone feed reader. We also tried to implement the full vision of Dave Winer's OPML spec. This means you can take other people's reading lists and "include" them as live resources inside your own lists browsing dynamic information hierarchies. When people would ask "what *is* it?" we frankly have never come up with a satisfactory answer. We've ended up moving Grazr into more of a "labs" / "technology demonstrator" kind of role with the possibility of coming back to it later if our other products take off.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">mikepk</dc:creator><pubDate>Fri, 16 Jan 2009 03:55:48 -0000</pubDate></item></channel></rss>