Comments on: Re: Idea for alternative RSS syncing system http://jens.mooseyard.com/2010/02/re-idea-for-alternative-rss-syncing-system/ Little boxes made of words, by Jens Alfke Sat, 04 Feb 2012 05:05:18 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: jens http://jens.mooseyard.com/2010/02/re-idea-for-alternative-rss-syncing-system/comment-page-1/#comment-3476 jens Sun, 07 Mar 2010 00:58:22 +0000 http://jens.mooseyard.com/?p=392#comment-3476 Because it requires complex software on the server side, that practically no one has the capability of installing. The client-side software is also pretty large and complex. Because it requires complex software on the server side, that practically no one has the capability of installing. The client-side software is also pretty large and complex.

]]> By: Uroflavin http://jens.mooseyard.com/2010/02/re-idea-for-alternative-rss-syncing-system/comment-page-1/#comment-3470 Uroflavin Fri, 05 Mar 2010 19:10:43 +0000 http://jens.mooseyard.com/?p=392#comment-3470 Why not use git? Why not use git?

]]> By: Brent http://jens.mooseyard.com/2010/02/re-idea-for-alternative-rss-syncing-system/comment-page-1/#comment-3433 Brent Thu, 11 Feb 2010 20:14:13 +0000 http://jens.mooseyard.com/?p=392#comment-3433 Would it be reasonable to also compress the read data in the form "for this feed, from august until november, the user has read everything"? This would mean that less data has to be stored on the server, and an initial synching would be much faster. Would it be reasonable to also compress the read data in the form “for this feed, from august until november, the user has read everything”? This would mean that less data has to be stored on the server, and an initial synching would be much faster.

]]> By: jens http://jens.mooseyard.com/2010/02/re-idea-for-alternative-rss-syncing-system/comment-page-1/#comment-3424 jens Tue, 09 Feb 2010 19:37:35 +0000 http://jens.mooseyard.com/?p=392#comment-3424 It's similar, except that all the smarts live on only one side (the client), so the pull is a simple HTTP GET and the push could theoretically be a PUT but in the real world is a really simple server-side script. This does limit it compared to what CouchDB can do, but it also means there's a very low bar for setting up the server. (Whereas it's very unlikely you'll be able to run an Erlang server process without an expensive hosting plan.) It’s similar, except that all the smarts live on only one side (the client), so the pull is a simple HTTP GET and the push could theoretically be a PUT but in the real world is a really simple server-side script.

This does limit it compared to what CouchDB can do, but it also means there’s a very low bar for setting up the server. (Whereas it’s very unlikely you’ll be able to run an Erlang server process without an expensive hosting plan.)

]]> By: Chris Anderson http://jens.mooseyard.com/2010/02/re-idea-for-alternative-rss-syncing-system/comment-page-1/#comment-3423 Chris Anderson Tue, 09 Feb 2010 19:09:51 +0000 http://jens.mooseyard.com/?p=392#comment-3423 Your REST-logging is almost exactly a description of how CouchDB replication works, except CouchDB works even when thousands of people are sharing the same data set at the same time. I described replication in more detail here for those who are interested: http://jchrisa.net/drl/_design/sofa/_show/post/CouchDB-Implements-a-Fundamental-Algorithm Your REST-logging is almost exactly a description of how CouchDB replication works, except CouchDB works even when thousands of people are sharing the same data set at the same time.

I described replication in more detail here for those who are interested:

http://jchrisa.net/drl/_design/sofa/_show/post/CouchDB-Implements-a-Fundamental-Algorithm

]]>