<?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>Wed, 24 Jun 2009 17:54:31 -0000</lastBuildDate><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><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-5161432</link><description>Mike,&lt;br&gt;&lt;br&gt;I may be one of the rare few who actually like Google Reader the way it is. I think if people take advantage of the feature set it has it would not be so overwhelming.  I do agree though with your points, there needs to be a new paradigm shift on how we view and consume RSS. It's very obvious from the string of "abandon your RSS readers" posts, that the email client model for RSS is simply not working anymore for the majority, and not the minority.&lt;br&gt;&lt;br&gt;I'm going to take a look at Grazr in the next few days. It looks like an interesting application. I'm not much for RSS in my Firefox sidebar, but willing to give it a test run with fairness.&lt;br&gt;&lt;br&gt;Mike</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">mfruchter</dc:creator><pubDate>Fri, 16 Jan 2009 03:40:59 -0000</pubDate></item><item><title>Re: One Password To Rule Them All</title><link>http://mikepk.com/2008/12/one-password-to-rule-them-all/#comment-4146560</link><description>Sometimes the price is worth the peace of mind to have to remember all these passwords.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">dcfemella</dc:creator><pubDate>Wed, 03 Dec 2008 10:35:39 -0000</pubDate></item><item><title>Re: One Password To Rule Them All</title><link>http://mikepk.com/2008/12/one-password-to-rule-them-all/#comment-4146477</link><description>It's a bit pricey for a password manager, but I got it on sale for half off (if I remember correctly). It's nice because it integrates with OS X's keychain and has browser plugins that can autofill and submit passwords on sites. It also has a strong password generator for registering sites which is handy. It will even remember multiple personalities if you have more than one login/password pair for a site. Overall, I'm pretty impressed with it.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">mikepk</dc:creator><pubDate>Wed, 03 Dec 2008 10:30:37 -0000</pubDate></item><item><title>Re: One Password To Rule Them All</title><link>http://mikepk.com/2008/12/one-password-to-rule-them-all/#comment-4146348</link><description>I have been trying to find a way to just have one password, and you have given me the answer.  Thanks!</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">dcfemella</dc:creator><pubDate>Wed, 03 Dec 2008 10:23:27 -0000</pubDate></item><item><title>Re: Roses By Any Other&amp;#8230;</title><link>http://mikepk.com/2008/06/roses-by-any-other/#comment-902008</link><description>LOL -- it's not just a web thing!  We got raked over the coals by someone on Twitter: "ftr, this is a dumb name for a product that has nothing to do with tigers or tacos (besides the shape): &lt;a href="http://www.tigertaco.com%22" rel="nofollow"&gt;http://www.tigertaco.com"&lt;/a&gt;&lt;br&gt;&lt;br&gt;I was tempted to make a point that there are few Orange animals (90% of our Tiger Tacos are orange), that it gave us a unique url, that we own the patent on the utility our product solves and could have called it anything while nobody can make/sell anything like our tacos (and "out smart" our brand name) and so obviously we thought a lot about the name, that we had to "challenge" peoples thinking before we'd be able to get them to consider what we do, and how it was indeed something we "fought about" internally ... and a million other things; basically it's like the reward that comes with having a child in that you get naming rights!&lt;br&gt;&lt;br&gt;But I didn't say anything; I figure there are just some people who refuse to get things and are just "haters" because of how small/bitter their own lives are in this great big world ... just saying names are a very personal thing and you shouldn't feel bad if not everyone loves you or gives you a chance just because they don't like your name!</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">chrismiller</dc:creator><pubDate>Tue, 15 Jul 2008 14:53:42 -0000</pubDate></item><item><title>Re: Innovation in a big corporation</title><link>http://mikepk.com/2008/06/innovation-in-a-big-corporation-2/#comment-620516</link><description>this is completely natural, and thereby trivial  ....  everything has a life span, you, me, the trees in the forest, and certainly companies, enterprises  ....&lt;br&gt;&lt;br&gt;knowing this, then how would you think?  design for fluidity, for one,  ll  others?</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">gregory</dc:creator><pubDate>Mon, 09 Jun 2008 01:49:34 -0000</pubDate></item><item><title>Re: Scoble Feedback</title><link>http://mikepk.com/?p=18#comment-571586</link><description>Yes, we're not a really like Twitter in the services we're currently offering. Grazr is basically a system for collecting information, blending it together into streams, filtering it, and allowing you to republish it (using widgets) on other pages. &lt;br&gt;&lt;br&gt;Grazr and Twitter are similar in some basic behind-the-scenes kinds of ways. We both deal with lots of user generated data, blended together and then presented in time sorted streams (very much like Twitter in that respect).  Unlike twitter, we're not a place to post. Since we're not the source of that data we have to collect the feeds from all over the web, making it in some respects a harder problem.  We also deal with a lot more data than Twitter since we aggregate the full content of feeds in those streams. One place where our job is easier is that, unlike Twitter, we're not aiming for real-time delivery of the data.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">mikepk</dc:creator><pubDate>Mon, 02 Jun 2008 09:25:27 -0000</pubDate></item></channel></rss>