<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Expanding on &#8220;twitter with a brain&#8221;</title>
	<atom:link href="http://stage.vambenepe.com/archives/1127/feed" rel="self" type="application/rss+xml" />
	<link>http://stage.vambenepe.com/archives/1127</link>
	<description>William Vambenepe&#039;s stage</description>
	<lastBuildDate>Tue, 07 Feb 2012 23:33:47 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: William Vambenepe &#8212; Integration patterns for social data: the Open Social Data Bus</title>
		<link>http://stage.vambenepe.com/archives/1127#comment-689</link>
		<dc:creator>William Vambenepe &#8212; Integration patterns for social data: the Open Social Data Bus</dc:creator>
		<pubDate>Thu, 20 May 2010 21:21:10 +0000</pubDate>
		<guid isPermaLink="false">http://stage.vambenepe.com/?p=1127#comment-689</guid>
		<description>[...] It has a delegated authorization model (though not quite as fine-grained as I&#8217;d like) [...] </description>
		<content:encoded><![CDATA[<p>[...] It has a delegated authorization model (though not quite as fine-grained as I&#8217;d like) [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: William Vambenepe &#8212; Don&#8217;t tell Facebook what you like, tell Twitter</title>
		<link>http://stage.vambenepe.com/archives/1127#comment-688</link>
		<dc:creator>William Vambenepe &#8212; Don&#8217;t tell Facebook what you like, tell Twitter</dc:creator>
		<pubDate>Tue, 04 May 2010 03:49:34 +0000</pubDate>
		<guid isPermaLink="false">http://stage.vambenepe.com/?p=1127#comment-688</guid>
		<description>[...] bus. It already has almost everything we need (though a more fine-grained authorization model, or a delegated authorization model, would make me more likely to allow sites to tweet on my behalf). What matters is the switch from [...] </description>
		<content:encoded><![CDATA[<p>[...] bus. It already has almost everything we need (though a more fine-grained authorization model, or a delegated authorization model, would make me more likely to allow sites to tweet on my behalf). What matters is the switch from [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: William Vambenepe &#8212; Taxonomy of Cloud Computing Benefits</title>
		<link>http://stage.vambenepe.com/archives/1127#comment-687</link>
		<dc:creator>William Vambenepe &#8212; Taxonomy of Cloud Computing Benefits</dc:creator>
		<pubDate>Mon, 11 Jan 2010 19:34:03 +0000</pubDate>
		<guid isPermaLink="false">http://stage.vambenepe.com/?p=1127#comment-687</guid>
		<description>[...] hasn&#8217;t yet created a major disaster (let&#8217;s see what 2010 has in store). I suggested a band-aid fix earlier, but this needs a real solution (the Cloud Security Alliance provides some guidance in this [...] </description>
		<content:encoded><![CDATA[<p>[...] hasn&#8217;t yet created a major disaster (let&#8217;s see what 2010 has in store). I suggested a band-aid fix earlier, but this needs a real solution (the Cloud Security Alliance provides some guidance in this [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: William (@vambenepe on Twitter)</title>
		<link>http://stage.vambenepe.com/archives/1127#comment-686</link>
		<dc:creator>William (@vambenepe on Twitter)</dc:creator>
		<pubDate>Tue, 01 Dec 2009 17:38:57 +0000</pubDate>
		<guid isPermaLink="false">http://stage.vambenepe.com/?p=1127#comment-686</guid>
		<description>Daniel: proxies may or may not be good for Twitter itself, but there is (almost) no way for them to stop them. It&#039;s in the hands of people writing apps that call the Twitter API. It&#039;s their choice whether to hard-core the Twitter endpoint URL or not.

As to whether or not such proxies would be good or bad for Twitter, it&#039;s not obvious in my mind. You could also say that all the Twitter clients are bad for Twitter too because they take eyeballs away from twitter.com where they could be fed advertising. But what would Twitter be today w/o them.</description>
		<content:encoded><![CDATA[<p>Daniel: proxies may or may not be good for Twitter itself, but there is (almost) no way for them to stop them. It&#8217;s in the hands of people writing apps that call the Twitter API. It&#8217;s their choice whether to hard-core the Twitter endpoint URL or not.</p>
<p>As to whether or not such proxies would be good or bad for Twitter, it&#8217;s not obvious in my mind. You could also say that all the Twitter clients are bad for Twitter too because they take eyeballs away from twitter.com where they could be fed advertising. But what would Twitter be today w/o them.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Daniel</title>
		<link>http://stage.vambenepe.com/archives/1127#comment-685</link>
		<dc:creator>Daniel</dc:creator>
		<pubDate>Tue, 01 Dec 2009 16:26:49 +0000</pubDate>
		<guid isPermaLink="false">http://stage.vambenepe.com/?p=1127#comment-685</guid>
		<description>While I think the idea has significant merit, it removes contact with Twitterees from the head Twitterer, Twitter itself, and therefore has the potential to limit their advertising business model as the system works now. If Twitter re-factors their system so that they can monitor and and measure activity through proxies that don&#039;t directly go to their endpoint, then they can preserve their potential to monetize their user base which is, after all, what most internet business models are about in some form or another. As it stands now, Twitter gains nothing and loses a lot with proxies.</description>
		<content:encoded><![CDATA[<p>While I think the idea has significant merit, it removes contact with Twitterees from the head Twitterer, Twitter itself, and therefore has the potential to limit their advertising business model as the system works now. If Twitter re-factors their system so that they can monitor and and measure activity through proxies that don&#8217;t directly go to their endpoint, then they can preserve their potential to monetize their user base which is, after all, what most internet business models are about in some form or another. As it stands now, Twitter gains nothing and loses a lot with proxies.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chuck Shotton</title>
		<link>http://stage.vambenepe.com/archives/1127#comment-684</link>
		<dc:creator>Chuck Shotton</dc:creator>
		<pubDate>Mon, 30 Nov 2009 14:01:45 +0000</pubDate>
		<guid isPermaLink="false">http://stage.vambenepe.com/?p=1127#comment-684</guid>
		<description>I think the idea of using Google App Engine (or the equivalent -- a Tomcat server somewhere) is a perfect fit for implementing quick and easy-to-deploy proxy &quot;modules&quot;. It should even be possible to stack several of them (a la Pipes) to get desired mix/match functionality for your Twitter proxy.

I&#039;ve got lots of the necessary code already implemented in my GAE version of a rssCloud server. It would make an interesting collaborative project to turn it into an open Twitter API platform and see what happens.

(Interestingly, it&#039;s only a small step from proxy to basic Twitter server...)</description>
		<content:encoded><![CDATA[<p>I think the idea of using Google App Engine (or the equivalent &#8212; a Tomcat server somewhere) is a perfect fit for implementing quick and easy-to-deploy proxy &#8220;modules&#8221;. It should even be possible to stack several of them (a la Pipes) to get desired mix/match functionality for your Twitter proxy.</p>
<p>I&#8217;ve got lots of the necessary code already implemented in my GAE version of a rssCloud server. It would make an interesting collaborative project to turn it into an open Twitter API platform and see what happens.</p>
<p>(Interestingly, it&#8217;s only a small step from proxy to basic Twitter server&#8230;)</p>
]]></content:encoded>
	</item>
</channel>
</rss>

