<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.3.1" -->
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	>
<channel>
	<title>Comments on: Cocoalicious 1.0b39: Local Persistence</title>
	<link>http://weblog.scifihifi.com/2006/01/03/cocoalicious-10b39-local-persistence/</link>
	<description>Buzz Andersen's Weblog</description>
	<pubDate>Thu, 20 Nov 2008 11:20:10 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.3.1</generator>
		<item>
		<title>By: ssp</title>
		<link>http://weblog.scifihifi.com/2006/01/03/cocoalicious-10b39-local-persistence/#comment-3413</link>
		<dc:creator>ssp</dc:creator>
		<pubDate>Sat, 07 Jan 2006 15:19:59 +0000</pubDate>
		<guid>http://weblog.scifihifi.com/2006/01/03/cocoalicious-10b39-local-persistence/#comment-3413</guid>
		<description>I have to admit my Cocoalicious use is rare as the javascript-based posting is quite efficient as well. But local caching is a real benefit (while delimport provides caching as well that's not browsable).

If I may suggest two little improvements for the app:
1. _Please_ make the date column more reasonable. I.e. using little space, having constant width. and not displaying the day of week. (Or, if you have time to kill, try doing something like the Finder in list view... but that could be a lot of effort).
2. Let us turn off the 'Rating' column. If you don't use star ratings, you can easily click there by accident and have to move the column off-screen to be on the safe side.

And perhaps more of a challenge:
3. Allow multiple selections and tag editing for that. A bit like iTunes. Sometimes I realise I have a number of posts which are related and I'd like to add a common tag to all of them. That's really hard to do with the web site. And Cocoalicious is already very good at renaming tags, so I had expected it to be able to do that and was a bit suprised it didn't.

</description>
		<content:encoded><![CDATA[<p>I have to admit my Cocoalicious use is rare as the javascript-based posting is quite efficient as well. But local caching is a real benefit (while delimport provides caching as well that&#8217;s not browsable).</p>
<p>If I may suggest two little improvements for the app:<br />
1. _Please_ make the date column more reasonable. I.e. using little space, having constant width. and not displaying the day of week. (Or, if you have time to kill, try doing something like the Finder in list view&#8230; but that could be a lot of effort).<br />
2. Let us turn off the &#8216;Rating&#8217; column. If you don&#8217;t use star ratings, you can easily click there by accident and have to move the column off-screen to be on the safe side.</p>
<p>And perhaps more of a challenge:<br />
3. Allow multiple selections and tag editing for that. A bit like iTunes. Sometimes I realise I have a number of posts which are related and I&#8217;d like to add a common tag to all of them. That&#8217;s really hard to do with the web site. And Cocoalicious is already very good at renaming tags, so I had expected it to be able to do that and was a bit suprised it didn&#8217;t.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: DeLynn Berry</title>
		<link>http://weblog.scifihifi.com/2006/01/03/cocoalicious-10b39-local-persistence/#comment-3411</link>
		<dc:creator>DeLynn Berry</dc:creator>
		<pubDate>Thu, 05 Jan 2006 22:38:24 +0000</pubDate>
		<guid>http://weblog.scifihifi.com/2006/01/03/cocoalicious-10b39-local-persistence/#comment-3411</guid>
		<description>I know this has been a long time coming, so congratulations! Can't wait to start using it on my machine.</description>
		<content:encoded><![CDATA[<p>I know this has been a long time coming, so congratulations! Can&#8217;t wait to start using it on my machine.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Lee</title>
		<link>http://weblog.scifihifi.com/2006/01/03/cocoalicious-10b39-local-persistence/#comment-3410</link>
		<dc:creator>Lee</dc:creator>
		<pubDate>Thu, 05 Jan 2006 15:34:47 +0000</pubDate>
		<guid>http://weblog.scifihifi.com/2006/01/03/cocoalicious-10b39-local-persistence/#comment-3410</guid>
		<description>I don’t think you need to get all the bookmarks (using /api/posts/all?) each time the user opens Cocoalicious. After the application is installed and logged in for the first time, the application should get all the bookmarks. After that you should get the updates incrementally (see below for how I think this can be done).

As you said there is not any method to retrieve the bookmarks that were modified with the existing API. Instead of getting all the bookmarks from the server on every load, you can perhaps do a full download on a scheduled basis (perhaps once a week or month). You should also allow a user the option to force a full download. I am not aware of many people’s experience with del.icio.us, but I know I very rarely edit existing posts (though I would be foolish to state that everyone uses it the same as I do).

I’ve looked through your code, and I love what you’ve done so far. I hope to have some time to work on some of the warnings you have in the code such as handling HTTP error status codes (such as 503’s). I don’t know if you are soliciting for developers on this though, so maybe I am not needed.

To get updates incrementally:
1. Get the list of dates and # of posts
/api/posts/dates?
2. Get the date of the last update
/api/posts/update
3. Retrieve a date from the list (from 1) that is greater than the date of the last update (from 2)
4. Remove all bookmarks from the local user’s DB* with this date (from 3)
5. Get list of bookmarks from server for this date
/api/post/get?&#38;dt=
6. Add the list to the DB
7. Goto 3

* I realize that this is not yet implemented and currently uses a plist. But if you get to using SQLite or CoreData then this would preferred in my opinion.</description>
		<content:encoded><![CDATA[<p>I don’t think you need to get all the bookmarks (using /api/posts/all?) each time the user opens Cocoalicious. After the application is installed and logged in for the first time, the application should get all the bookmarks. After that you should get the updates incrementally (see below for how I think this can be done).</p>
<p>As you said there is not any method to retrieve the bookmarks that were modified with the existing API. Instead of getting all the bookmarks from the server on every load, you can perhaps do a full download on a scheduled basis (perhaps once a week or month). You should also allow a user the option to force a full download. I am not aware of many people’s experience with del.icio.us, but I know I very rarely edit existing posts (though I would be foolish to state that everyone uses it the same as I do).</p>
<p>I’ve looked through your code, and I love what you’ve done so far. I hope to have some time to work on some of the warnings you have in the code such as handling HTTP error status codes (such as 503’s). I don’t know if you are soliciting for developers on this though, so maybe I am not needed.</p>
<p>To get updates incrementally:<br />
1. Get the list of dates and # of posts<br />
/api/posts/dates?<br />
2. Get the date of the last update<br />
/api/posts/update<br />
3. Retrieve a date from the list (from 1) that is greater than the date of the last update (from 2)<br />
4. Remove all bookmarks from the local user’s DB* with this date (from 3)<br />
5. Get list of bookmarks from server for this date<br />
/api/post/get?&amp;dt=<br />
6. Add the list to the DB<br />
7. Goto 3</p>
<p>* I realize that this is not yet implemented and currently uses a plist. But if you get to using SQLite or CoreData then this would preferred in my opinion.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
