<?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: Thoughts on Redesigning a Framework (Updated)</title>
	<atom:link href="http://lukhnos.org/objectiveflickr/blog/archives/14/feed" rel="self" type="application/rss+xml" />
	<link>http://lukhnos.org/objectiveflickr/blog/archives/14</link>
	<description>Flickr API Library for Mac and iPhone</description>
	<lastBuildDate>Thu, 28 May 2009 16:27:11 -0700</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.3</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: lukhnos</title>
		<link>http://lukhnos.org/objectiveflickr/blog/archives/14/comment-page-1#comment-24814</link>
		<dc:creator>lukhnos</dc:creator>
		<pubDate>Wed, 05 Nov 2008 20:06:27 +0000</pubDate>
		<guid isPermaLink="false">http://lukhnos.org/objectiveflickr/blog/archives/14#comment-24814</guid>
		<description>Hi iDVB,

I apologize for not being able to devote more time to this project. My original plan was to (1) drop in the already-finished LFHTTPRequest as the stand-in of OFHTTPRequest/OFPOSTRequest, which are showing their age and design constraints, (2) offer a libxml2-based replacement of NSXMLDocument that coverts Flickr response block directly to property lists (NSDictionary/NSArray/etc.). But apparently fixing the framework is harder, especially when I know there are projects depending on the trunk.

A better idea might be to offer a branch out of the trunk. Do you find it a sound idea?</description>
		<content:encoded><![CDATA[<p>Hi iDVB,</p>
<p>I apologize for not being able to devote more time to this project. My original plan was to (1) drop in the already-finished LFHTTPRequest as the stand-in of OFHTTPRequest/OFPOSTRequest, which are showing their age and design constraints, (2) offer a libxml2-based replacement of NSXMLDocument that coverts Flickr response block directly to property lists (NSDictionary/NSArray/etc.). But apparently fixing the framework is harder, especially when I know there are projects depending on the trunk.</p>
<p>A better idea might be to offer a branch out of the trunk. Do you find it a sound idea?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: iDVB</title>
		<link>http://lukhnos.org/objectiveflickr/blog/archives/14/comment-page-1#comment-24811</link>
		<dc:creator>iDVB</dc:creator>
		<pubDate>Wed, 05 Nov 2008 15:12:47 +0000</pubDate>
		<guid isPermaLink="false">http://lukhnos.org/objectiveflickr/blog/archives/14#comment-24811</guid>
		<description>I&#039;m currently using a version of ObjectiveFlickr that I ported (threw many days of hair pulling) to &quot;the-device-and-the-OS-that-shalt-not-be-named-although-I-think-it-can-now-be-named&quot; 

It&#039;s combines TouchXML, ObjectiveFlickr and a fair bit of code changes and constant changes.

I now have it working 100% and am currently working on an app now.

Please let me know if you&#039;re interested in knowing more. I&#039;ll be keeping a close eye on your progress in this area as it will definitely affect our project.</description>
		<content:encoded><![CDATA[<p>I&#8217;m currently using a version of ObjectiveFlickr that I ported (threw many days of hair pulling) to &#8220;the-device-and-the-OS-that-shalt-not-be-named-although-I-think-it-can-now-be-named&#8221; </p>
<p>It&#8217;s combines TouchXML, ObjectiveFlickr and a fair bit of code changes and constant changes.</p>
<p>I now have it working 100% and am currently working on an app now.</p>
<p>Please let me know if you&#8217;re interested in knowing more. I&#8217;ll be keeping a close eye on your progress in this area as it will definitely affect our project.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: iDVB</title>
		<link>http://lukhnos.org/objectiveflickr/blog/archives/14/comment-page-1#comment-24549</link>
		<dc:creator>iDVB</dc:creator>
		<pubDate>Tue, 14 Oct 2008 00:47:44 +0000</pubDate>
		<guid isPermaLink="false">http://lukhnos.org/objectiveflickr/blog/archives/14#comment-24549</guid>
		<description>Have you considered porting ObjectiveFlickr for the iPhone?</description>
		<content:encoded><![CDATA[<p>Have you considered porting ObjectiveFlickr for the iPhone?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chris</title>
		<link>http://lukhnos.org/objectiveflickr/blog/archives/14/comment-page-1#comment-24203</link>
		<dc:creator>Chris</dc:creator>
		<pubDate>Tue, 23 Sep 2008 13:42:10 +0000</pubDate>
		<guid isPermaLink="false">http://lukhnos.org/objectiveflickr/blog/archives/14#comment-24203</guid>
		<description>For me the most important feature is compatibility with the iPhone SDK. I&#039;m already using ObjectiveFlickr using the iPhone Simulator, but as long as NSXMLDocument is referenced, my app cannot be deployed on a real iPhone.

Do you have a target date for a iPhone SDK compatible version of Flickr?

Keep up the good work!</description>
		<content:encoded><![CDATA[<p>For me the most important feature is compatibility with the iPhone SDK. I&#8217;m already using ObjectiveFlickr using the iPhone Simulator, but as long as NSXMLDocument is referenced, my app cannot be deployed on a real iPhone.</p>
<p>Do you have a target date for a iPhone SDK compatible version of Flickr?</p>
<p>Keep up the good work!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jean-Pierre</title>
		<link>http://lukhnos.org/objectiveflickr/blog/archives/14/comment-page-1#comment-23677</link>
		<dc:creator>Jean-Pierre</dc:creator>
		<pubDate>Mon, 25 Aug 2008 19:31:16 +0000</pubDate>
		<guid isPermaLink="false">http://lukhnos.org/objectiveflickr/blog/archives/14#comment-23677</guid>
		<description>Great,

I&#039;ve just released a plugin for iPhoto using ObjectiveFlickr for non-commercial use.

I hope to use your future API in the future.

Thanks

Jean-Pierre

http://www.devconseil.com</description>
		<content:encoded><![CDATA[<p>Great,</p>
<p>I&#8217;ve just released a plugin for iPhoto using ObjectiveFlickr for non-commercial use.</p>
<p>I hope to use your future API in the future.</p>
<p>Thanks</p>
<p>Jean-Pierre</p>
<p><a href="http://www.devconseil.com" rel="nofollow">http://www.devconseil.com</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Michael</title>
		<link>http://lukhnos.org/objectiveflickr/blog/archives/14/comment-page-1#comment-22580</link>
		<dc:creator>Michael</dc:creator>
		<pubDate>Mon, 28 Jul 2008 18:24:40 +0000</pubDate>
		<guid isPermaLink="false">http://lukhnos.org/objectiveflickr/blog/archives/14#comment-22580</guid>
		<description>I&#039;ve been using ObjectiveFlickr for about a year now and I&#039;ve run into limitations. I used it in conjunction with NSOperation/Queue and I&#039;ve had a problem where my app started using a *huge* number of mach ports. Seems to go back to obj-flickrs&#039; NSXMLDocument dependency. It&#039;s been a while but I can&#039;t say for sure. Anyway, I haven&#039;t shipped an app with it yet, so I have no problem with the API changing.

Thanks for ObjectiveFlickr.

Michael</description>
		<content:encoded><![CDATA[<p>I&#8217;ve been using ObjectiveFlickr for about a year now and I&#8217;ve run into limitations. I used it in conjunction with NSOperation/Queue and I&#8217;ve had a problem where my app started using a *huge* number of mach ports. Seems to go back to obj-flickrs&#8217; NSXMLDocument dependency. It&#8217;s been a while but I can&#8217;t say for sure. Anyway, I haven&#8217;t shipped an app with it yet, so I have no problem with the API changing.</p>
<p>Thanks for ObjectiveFlickr.</p>
<p>Michael</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Greg</title>
		<link>http://lukhnos.org/objectiveflickr/blog/archives/14/comment-page-1#comment-21786</link>
		<dc:creator>Greg</dc:creator>
		<pubDate>Tue, 15 Jul 2008 16:36:37 +0000</pubDate>
		<guid isPermaLink="false">http://lukhnos.org/objectiveflickr/blog/archives/14#comment-21786</guid>
		<description>I think backward compatibility with previous interfaces is less important than making an iPhone compatible version available quickly.  Whichever path would result in the quickest iPhone-compatible library would probably please the most developers.  My two cents ...</description>
		<content:encoded><![CDATA[<p>I think backward compatibility with previous interfaces is less important than making an iPhone compatible version available quickly.  Whichever path would result in the quickest iPhone-compatible library would probably please the most developers.  My two cents &#8230;</p>
]]></content:encoded>
	</item>
</channel>
</rss>
