To what extent should Google Reader be cloned?

Discussion:

Grant Lucas

2013-04-14 01:29:57 UTC

I'm working on setting up a RSS sync service and the main initial task
is cloning the existing Google Reader API. My question is, to what
extent should the Google Reader API be cloned? When we're saying clone,
are we talking even including "com.google" in calls such as
"user/-/state/com.google/read"?

Should item IDs still be "tag:google.com,2005:reader/item/<###>"? I
guess when I first thought about a clone, it would be more generic, but
now I'm not sure after seeing some other clone work in progress.

Any advice, thoughts, and help greatly appreciated.

--
Grant Lucas
http://grantlucas.com

Barijaona Ramaholimihaso

2013-04-14 05:22:10 UTC

Permalink

Post by Grant Lucas
When we're saying clone,
are we talking even including "com.google" in calls such as
"user/-/state/com.google/read"?

Personally, I see no problem in keeping "com.google" in this context.

Post by Grant Lucas
Should item IDs still be "tag:google.com,2005:reader/item/<###>"?

If the original feed provides GUIDs, you should make reasonable efforts to check their correctness and use them if possible.
If you intend to migrate user's data from Google Reader, you may try to reuse existing Google Reader's tags.

Otherwise, you should forge your own tags to avoid confusion with similar created elsewhere. I agree with opinions expressed in other messages here about RFC4151 respect and use of a hash build from publication date, article URL and article title.

--
Barijaona Ramaholimihaso
https://github.com/ViennaRSS/vienna-rss

Grant Lucas

2013-04-14 21:13:35 UTC

Permalink

Thanks for the input Barijaona.

As an RSS reader creator, hypothetically, how difficult would it be for
you to change out calls using "user/-/state/com.google/read" for
something more generic?

For example if a sync API still used a similar method to google reader
with the "xt" property but didn't use that specific string to exclude
read articles? Or from your perspective, would it be better for a sync
service to accept "user/-/state/com.google/read" and map it our end to
our own implementation?
--
Grant Lucas
http://grantlucas.com

Post by Barijaona Ramaholimihaso

Post by Grant Lucas
When we're saying clone,
are we talking even including "com.google" in calls such as
"user/-/state/com.google/read"?

Personally, I see no problem in keeping "com.google" in this context.

Post by Grant Lucas
Should item IDs still be "tag:google.com,2005:reader/item/<###>"?

If the original feed provides GUIDs, you should make reasonable efforts to check their correctness and use them if possible.
If you intend to migrate user's data from Google Reader, you may try to reuse existing Google Reader's tags.
Otherwise, you should forge your own tags to avoid confusion with similar created elsewhere. I agree with opinions expressed in other messages here about RFC4151 respect and use of a hash build from publication date, article URL and article title.
--
Barijaona Ramaholimihaso
https://github.com/ViennaRSS/vienna-rss
_______________________________________________
RSS-Sync mailing list
http://lists.ranchero.com/listinfo.cgi/rss-sync-ranchero.com

Charlie O'Keefe

2013-04-14 23:49:34 UTC

Permalink

Keep in mind that if a company designs something with âcompanyname.comâ in
its name, it is very often for namespacing reasons, rather than an
intention to tie something to their name and their product.

It's saying, in effect, âif these names are thrown into a codebase with a
bunch of other code contributed by other parties, it shouldn't cause any
name collisionsâ.

Post by Grant Lucas
Thanks for the input Barijaona.
As an RSS reader creator, hypothetically, how difficult would it be for
you to change out calls using "user/-/state/com.google/read" for
something more generic?
For example if a sync API still used a similar method to google reader
with the "xt" property but didn't use that specific string to exclude
read articles? Or from your perspective, would it be better for a sync
service to accept "user/-/state/com.google/read" and map it our end to
our own implementation?
--
Grant Lucas
http://grantlucas.com
On Sun, Apr 14, 2013 at 08:22, Barijaona Ramaholimihaso <

Post by Barijaona Ramaholimihaso

Post by Grant Lucas
When we're saying clone,
are we talking even including "com.google" in calls such as
"user/-/state/com.google/read"?

Personally, I see no problem in keeping "com.google" in this context.

Post by Grant Lucas
Should item IDs still be "tag:google.com,2005:reader/item/<###>"?

If the original feed provides GUIDs, you should make reasonable efforts

to check their correctness and use them if possible.

Post by Barijaona Ramaholimihaso
If you intend to migrate user's data from Google Reader, you may try to

reuse existing Google Reader's tags.

Post by Barijaona Ramaholimihaso
Otherwise, you should forge your own tags to avoid confusion with

similar created elsewhere. I agree with opinions expressed in other
messages here about RFC4151 respect and use of a hash build from
publication date, article URL and article title.

Post by Barijaona Ramaholimihaso
--
Barijaona Ramaholimihaso
https://github.com/ViennaRSS/vienna-rss
_______________________________________________
RSS-Sync mailing list
http://lists.ranchero.com/listinfo.cgi/rss-sync-ranchero.com

_______________________________________________
RSS-Sync mailing list
http://lists.ranchero.com/listinfo.cgi/rss-sync-ranchero.com

Grant Lucas

2013-04-14 16:45:32 UTC

Permalink

Post by Barijaona Ramaholimihaso

Post by Grant Lucas
When we're saying clone,
are we talking even including "com.google" in calls such as
"user/-/state/com.google/read"?

Personally, I see no problem in keeping "com.google" in this context.

Post by Grant Lucas
Should item IDs still be "tag:google.com,2005:reader/item/<###>"?

If the original feed provides GUIDs, you should make reasonable efforts to check their correctness and use them if possible.
If you intend to migrate user's data from Google Reader, you may try to reuse existing Google Reader's tags.
Otherwise, you should forge your own tags to avoid confusion with similar created elsewhere. I agree with opinions expressed in other messages here about RFC4151 respect and use of a hash build from publication date, article URL and article title.
--
Barijaona Ramaholimihaso
https://github.com/ViennaRSS/vienna-rss
_______________________________________________
RSS-Sync mailing list
http://lists.ranchero.com/listinfo.cgi/rss-sync-ranchero.com

Barijaona Ramaholimihaso

2013-04-15 04:05:05 UTC

Permalink

No formal decision has yet been taken, but the Vienna RSS team is attempting to support as many sync engines as possible.
This can probably be done through subclassing of a generic class (or, in Objective-C lingo, a protocol implemented by different classes). So, the approach you suggest is doable.

But other software makers might prefer supporting only a few popular servers (Feedly…), so you'd better avoid important divergences with Google Reader.

Post by Grant Lucas
As an RSS reader creator, hypothetically, how difficult would it be for
you to change out calls using "user/-/state/com.google/read" for
something more generic?
For example if a sync API still used a similar method to google reader
with the "xt" property but didn't use that specific string to exclude
read articles? Or from your perspective, would it be better for a sync
service to accept "user/-/state/com.google/read" and map it our end to
our own implementation?

Grant Lucas

2013-04-15 14:37:16 UTC

Permalink

Agreed. Thanks for the input.
--
Grant Lucas
http://grantlucas.com

Post by Barijaona Ramaholimihaso
No formal decision has yet been taken, but the Vienna RSS team is attempting to support as many sync engines as possible.
This can probably be done through subclassing of a generic class (or, in Objective-C lingo, a protocol implemented by different classes). So, the approach you suggest is doable.
But other software makers might prefer supporting only a few popular servers (Feedly…), so you'd better avoid important divergences with Google Reader.

_______________________________________________
RSS-Sync mailing list
http://lists.ranchero.com/listinfo.cgi/rss-sync-ranchero.com

Grant Lucas

2013-04-14 21:11:01 UTC

Permalink

Adding to my own question here as I thought about it more over night.

Would it make sense to create a sync API that is more generic than a
straight copy of the GReader API, and then alias/map all the Google
reader specific calls to the generic API? This would allow for the short
term Google Reader drop in, but also help in developing a more generic
open reader api standard.

I would love to work with some people here to hash out an Open Reader
API spec that is essentially a Google Reader clone, but generic and
cleaned up a little.

Is there interest in this? If so, what can I do to get the ball rolling?
It'd be great to get it fleshed out as soon as possible, and would be
great to see if we can get others implementing a Google Reader clone on
board with supporting this.

I think this would help mitigate the issues where everybody's Google
reader clones act slightly different.
--
Grant Lucas
http://grantlucas.com

Post by Grant Lucas
I'm working on setting up a RSS sync service and the main initial task
is cloning the existing Google Reader API. My question is, to what
extent should the Google Reader API be cloned? When we're saying clone,
are we talking even including "com.google" in calls such as
"user/-/state/com.google/read"?
Should item IDs still be "tag:google.com,2005:reader/item/<###>"? I
guess when I first thought about a clone, it would be more generic, but
now I'm not sure after seeing some other clone work in progress.
Any advice, thoughts, and help greatly appreciated.
--
Grant Lucas
http://grantlucas.com
_______________________________________________
RSS-Sync mailing list
http://lists.ranchero.com/listinfo.cgi/rss-sync-ranchero.com

Grant Lucas

2013-04-14 16:45:38 UTC

Permalink

Devon Govett

2013-04-14 20:44:50 UTC

Permalink

I have also been working on cloning the Google Reader API, and I have tried to clone everything as exactly as I can, down to the HTTP headers and status codes that Google responds with, just so that as many apps using Google's API continue to work as possible. Also, if you're interesting in helping out an existing project, my project is open source and fairly far along. You can find it at https://github.com/devongovett/reader. It would be nice not to duplicate effort, but if you're not interested I won't be offended. :)

Devon

Grant Lucas

2013-04-15 14:39:57 UTC

Permalink

Hi there Devon. After a few false starts, I agree that at this point,
minimizing duplication of effort would be good. I've forked your reader
and aim to contribute as much as I can. I just need to wrap my head
around what's done so far and the processes etc in the next few nights.

Looking forward to contributing!
--
Grant Lucas
http://grantlucas.com

Post by Devon Govett
I have also been working on cloning the Google Reader API, and I have tried to clone everything as exactly as I can, down to the HTTP headers and status codes that Google responds with, just so that as many apps using Google's API continue to work as possible. Also, if you're interesting in helping out an existing project, my project is open source and fairly far along. You can find it at https://github.com/devongovett/reader. It would be nice not to duplicate effort, but if you're not interested I won't be offended. :)
Devon

_______________________________________________
RSS-Sync mailing list
http://lists.ranchero.com/listinfo.cgi/rss-sync-ranchero.com