Cocoalicious 1.0b39: Local Persistence
I’ve been slowly hacking away at one of the holy grails of Cocoalicious development–local caching of posts–for quite sometime now, and I think I finally have a build ready for public consumption. That is to say, it’s very far from perfect, but I’ve been living on it for about a week now, and it seems usable and unlikely to do much harm. And, really, what more can we ask from our software?
As a del.icio.us user, I’m thrilled to finally have local persistence going, because it means:
- I now have an automatic local backup of my del.icio.us bookmarks.
- I can actually access my bookmarks during del.icio.us’ occasional hiccups. Now, if you start Cocoalicious while del.icio.us is down (or your computer is off the network), it will fall back on its local post cache (and display “[Offline]” in the window title to let you know you’re actually looking at the cache).
- I no longer have to wait for Cocoalicious to download my entire post list unless there has actually been a change on the server side. Cocoalicious now stores its last refresh time locally and consults the del.icio.us API’s last modified time to make sure a refresh is actually needed.
That’s the good news. The bad news is that local persistence still has a lot of rough edges. Here’s some caveats to be aware of:
- Currently, if you do a post, it will cause the API’s last modified time to get updated, meaning that the next time you refresh or restart Cocoalicious, it will think it needs to do a full download (since the API’s last modified time is after the local last refresh time) even though that may not be necessary.
- You will only be able to log in in offline mode if you have the preferences set to automatically log in with a certain account. This sucks big time, but I’m going to need to overhaul the authentication code to fix it.
- If you try to post while del.icio.us is down, your post will get written to the local cache but not del.icio.us, meaning that the next time you do a refresh, it will disappear. I plan to eventually fix this by giving Cocoalicious the ability to queue posts for later submission to del.icio.us.
- I really should add a way to force a full download in case of weirdness (for example, I have occasionally seen the API last modified date be off in strange ways). Perhaps holding down shift while launching the app or refreshing?
- Syncing is currently quite dumb. In fact, what Cocoalicious does right now isn’t really syncing, since the del.icio.us API makes true syncing nearly impossibly to do. It can only tell you when a user’s bookmarks were last modified, not how (e.g. what was modified, what was added, what was deleted), so it’s essentially impossible to get away from always downloading the user’s entire collection of posts. Not sure I’m going to be able to solve that one without some help from the del.iciol.us side, although I’m open to creative suggestions.
- The local cache is in the form of an XML plist, which actually gets completely rewritten every time you post. Ideally, Cocoalicious would be able to simply insert new posts to the cache without rewriting the entire thing. Perhaps someday we’ll move to Core Data (or simply SQLite)…
- One of the obvious killer features of a local cache would be the ability to maintain private bookmarks. I’d eventually like to provide a facility for this in Cocoalicious, although this build doesn’t have it.
All of that aside, though, I think this release greatly bolsters Cocoalicious’ utility by adding a feature that almost certainly could only be done on the client side, and it hopefully paves the way for some more interesting features in the future. Be sure to give it a whirl!
January 5th, 2006 at 7:34 am
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?&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.
January 5th, 2006 at 2:38 pm
I know this has been a long time coming, so congratulations! Can’t wait to start using it on my machine.
January 7th, 2006 at 7:19 am
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.