Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature] Add in a key to store each post's article #8

Open
jackyliang opened this issue Mar 3, 2015 · 8 comments
Open

[Feature] Add in a key to store each post's article #8

jackyliang opened this issue Mar 3, 2015 · 8 comments

Comments

@jackyliang
Copy link
Contributor

I would love a feature that downloads the article from each post as well, given it a key of article, so the cli app could have an offline mode where all posts are accessible once cached. This idea came since I'm about to head onto the plane, and I'm not satisfied with any of my iPhone reading apps [there's no Coven for iOS, unfortunately]

@clooth
Copy link

clooth commented Mar 3, 2015

There will be Coven for iOS once I finish it. With offline cache :)

@jackyliang
Copy link
Contributor Author

@clooth Offline cache with articles?

@clooth
Copy link

clooth commented Mar 3, 2015

@jackyliang Yes, the application will cache the article pages as much as it can. It can be a bit tricky but in the end, it will have the functionality.

@jackyliang
Copy link
Contributor Author

@clooth I think it would be better on an architectural standpoint for @goddamnyouryan to update the API for coven-api to return the article as part of the API instead of rolling a custom Reading Mode solution. I don't know Ruby at all so I can't personally do it.. That said, for now, I'm also going to roll a client-side solution to get the article as part of this issue, until maybe if the API can be updated =).

@clooth
Copy link

clooth commented Mar 4, 2015

@jackyliang I didn't know you wanted it to be as a "reading mode", I am planning on using a custom URL Cache for storing the article pages. We could utilise an existing service like Readability for grabbing an article's contents.

From an architectural standpoint I believe it would be best if @goddamnyouryan would implement a way to detect duplicate article links and give us a unique field to match against, instead of replacing the set of spidered articles each time.

I'm currently doing this locally (on the app) by using the URL of the article as a primary key (for the time being, I know it's unrelieable).

Edit: It seems like I have misread the original issue title, and was in fact thinking that the issue was to store a unique key for an article, or something. Still a good discussion, albeit sort of unrelated.

@goddamnyouryan
Copy link
Owner

We currently do scope by article URL. That is to say if two services have the same article, only the first one will make it into Coven.

I mostly refresh the articles (aka delete them all and start over) when I do a sync to provide varied content that is inline with the rankings of the various articles on the services.

I guess I'm still confused what it is you guys are looking for me to do?

@jackyliang
Copy link
Contributor Author

Hi Ryan.

Pardon my poor explanation.

I meant that for each post, add a cleaned up article with the key article, i.e. for this article.

"article":"It’s 2015, but Windo​ws 93 is finally ready. Your new favorite operating system is here and it’s weird as hell. The browser-based OS makes us     thirst for what could’ve been if Microsoft didn’t skip between Windows 3.X and Windows 95."

This way, I can run coven reload on my CLI app, and all articles would, at the same time, be saved to my local cache, and I can take all the articles everywhere.

@goddamnyouryan
Copy link
Owner

Ahhh that makes sense. I unfortunately don't have enough time to implement this into the API at the moment but if you guys want to integrate readability or some other such service (preferably a free one) to pull in that data when we do the syncing feel free!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants