Plans for this fork and relation to mk-fg

[COLABORATI]

Hi, playing around with mk-fg/feedjack I found your repo - from what I understand your changes are based on the current master of his feedjack branch, however I see no pull request on his repo from your changes here. I do not understand the current situation regarding this code, would you like to explain? Is this the new 'main' repo for feedjack? Thanks for your attention!

[allo-]

Good you asked, i just wanted to open an own issue to copy my statement here.

X-Post: https://github.com/mk-fg/feedjack/issues/5#issuecomment-236904461

---

Hi. I am activly working on the code currently, but step by step. The result will finally be hard to merge, as i changed some concepts, urls, etc.

Further i plan to make it pep8 compliant after the refactoring, which will make it very hard to merge this branch. I delay it for old code until other refactoring is done, so there is no big patch between the branches, which makes it hard to trace patches. When i do this, there will be a lot of white space change, which may be possible to be filtered with "diff -b", but much will be an rather ugly patch.

Differences (done / planned):

• Broke most urls. Removed the whole generation of hundreds of permutations of /since/.../asc/, /asc/since/.../ stuff and replaced it with easier to parse GET-Parameters.
• Reintroduced Feed groups (can probably be merged)
• Removed Tag Cloud support (may be added again later, probably with some django package providing this)
• Probably broke all themes but plain. Themes should be done either as ".css" or as replacement html with Django App templates, which allow to inherit from another packages base.html. Will remove legacy themes soon, which can be restored and rewritten for the new structure from git history. Current plain theme needs to be polished as well, especially the views whiche are not post-list.html, which weren't supported previously.
• Added django-registration-redux for user accounts and marking posts as read (or important, read later, etc.)
• Will break Site selection via weighting parts of the url and replace it with django.contrib.sites to get the current site via get_current_site, which can be extended by other django packages, if needed.
• Probably some caching will be redone, especially were marking posts as read needs to invalidate the page cache.
• As pagination doesn't work when posts on the current page are marked as read while the page is generated for marked=U (unread) posts, the pagination will be completely date-based. So the "next" button will lead to marked=U&since=last_post_on_page_date

Finally i plan to have Site views, which are just like a planet and User views, which associate a subset of the feeds with a user account, like a newsreader. If there is time and ambition, a a control panel would be nice, where users can suggest new feeds, which can later be subscribed by all Users and Sites and a admin control panel, where the administrator can accept new feeds.

So the data model should be something like:

• Feed (feeds, which are fetched)
• fj.Site (planet, associated with a django)
• User
• Subscriber (associating a Feed with a User or fj.Site)

This means my fork is currently already incompatible with this one, @mk-fg may or may not want to use it later. I started doing that big changes when i heard, that he's not very active here at the moment anymore. I cannot guarantee how long i will stay active on my fork, but i have some plans (see the list above and the issues there)

[allo-]

And a comment on stability: I add migrations from commit to commit, but before i finished the big refactorings i cannot really guarantee for any upgrades.

I upgraded my installation from the allo/cato branch merge to the latest mk-fg commit and it required quite some efford with installing older django versions to be able to migrate with south (moving the old migrations back), upgrading django again and migrate with the new migrations and in between i needed to remove columns via SQL and fake some migrations from other django packages.

So the current plan is getting the package in a good shape and provide then a release, from which smooth upgrades will be possible to each later version. Everything before may require some efford until it works.

[allo-]

With good shape i mean, that i try to simplify what the package does and remove all clever but possibly hard to maintain features, i.e. using django-Sites for determining the current site or trying to move all get_context from fjlib to django context processors and so on.

That's the reason why there is no pull request, as i do not know how much @mk-fg approves these changes. Currently i am cleaning up and extending it for my requirements (mostly a feedreader, still in form of a planet site) and maybe later a site providing planets / feedreaders to more users, as described above. Depending on how much merge will be possible / how active his fork gets again, this may result in two projects. I would not mind to rename this one later, when it's needed.

[COLABORATI]

Thanks for the quick answer! So wouldn't it make sense to make a new repo for this, like e.g. feedjack-ng or similar? Also it would be nice to have an actively developed feedjack in pypi, so maybe it should be renamed to enable posting to pypi with a different name?

Regarding django-registration-redux - I have not yet worked with that special app and I am sure there must be a reason why you make it a hard dependency, but intuitively I feel like that user registration should be part of an example app that uses feedjack, which could live in a seperate 'example project' repo. Wouldn't it be better to keep all user relations just to the built-in Django user and not pull in dependencies to auth apps? It would be great to still be able to use one of the other auth and user registration packages, don't you think so?

Also I would like to just wildly throw in the suggestion of putting the feed fetching into a dedicated piece of software, I found this recent release of riko very interesting, also the author would like to add some GUI (that could be feedjack!) and support for some kind of (lightweight) workflow engine like luigi or airflow. A combination of these would be a very good step into the direction of a 'ultimate feedreader' - also integration of machine learning could be done more easily.

From what I understand you are adding lots of user related features to feedjack, right? I have seen feedjack as a library or a feed management backend - a user frontend with specific user related features is of course very nice to have, but shouldn't this be a separate project?

Just another minor point, but why remove the tag cloud? Everybody loves them :)

[COLABORATI]

BTW I am just speculating (brainstorming) on a high level and do not feel authorized in any way to critizise your design decisions, so please do not interpret these suggestions as offense, they are just ideas I had playing around with feedjack and other feed readers.

Regarding the user facing features side of feedjack it could be a huge longterm win to use wagtail - lots of cms features right out of the box.

I would very much like when Feedjack would bring just the glue between several frontend / backend options, but still with its own django-admin ui for a basic setup. A wagtail user frontend could import feedjack models and build on that, and feedjack itself could be extended to optionally use riko or similar tools to implement a growing set of feed sources (twitter, fb, pictures, pro data stream services, whatever) and methods for mangling / working with the input sources data.

[mk-fg]

For my part of the story, briefly:

Don't think I've touched the code since @allo- has opened mk-fg/feedjack#7, simply because of other priorities.

Only worked on the features and merging stuff as I needed them for my own feed aggregators, but don't think I've found time to read these for a few years now, so obviously don't really need anything from the code either.

I.e. there's probably no reason to look at my fork at all at this point, safe to consider it to be abandoned.

---

Concerning specific points that were raised here (in no particular order):

The result will finally be hard to merge That's the reason why there is no pull request, as i do not know how much @mk-fg approves these changes.

Don't think my opinion matters here, and I shouldn't be (and cannot be, unfortunately) a release manager of any kind for this project.

I'd suggest simply treating these as non-issues, forgetting that mk-fg/feedjack exists entirely.

PyPI status

My "mk.fg" account on pypi has "owner" role for Feedjack package.

When I was still using the thing, simply asked pypi package owner (iElectric) to give me upload access to it, as they didn't seem to be using the index entry anyway, and got an "ok" response straight away.

Given that thing already got forked a few times, likely not too heavy use (didn't check), and abandoned status of mk-fg/feedjack, don't see any problem replacing my pypi entry role with @allo-. Don't think iElectric or anyone else would possibly object.

Just leave a note with your pypi acc name here and I'll try to do it right away.

mk-fg/feedjack github repo status

Repository is marked as a "root for all forks", as after getting pypi entry role, also asked github to split repo from the original fork tree, as it is now a source for pypi package, so more like a thing on its own than a fork.

I'll add a note about it being abandoned to the top of the README there, so it'd be more obvious, but would obviously rather keep all repos under mk-fg as my forks, not a community thing. One solution to this "original repo" thing of github (purely site UI issue) is to create github org, and have e.g. "feedjack/feedjack" repo, and however many personal forks, as I've seen done with e.g. mk-fg/dracut-crypt-sshd -> dracut-crypt-ssh/dracut-crypt-ssh. Unfortunately, I think in involves breaking fork tree once again (just ask github), but probably worth doing for any project with >1 forks.

---

Hope that clears things up a bit, sorry that it's a bit of a mess at the moment, mostly my fault, I think.

Cheers!

[allo-]

@COLABORATI

• I do not know, who owns which project at pypi, i think mk-fg made an own one. This would be a good reason to come up with a new name.
• The project is still a fork, so i see no need to make a whole new repository here. I am a bit tempted to kill all django migrations as well at the "1.0" point when i think i cleaned up and refactored everything to a nice state to avoid people going to 20 migrations which add and remove tables. But deciding such things still has time.
• django-registration-redux is mostly a set of templates to be used with django.contrib.auth and adds features like double-opt-in for verified e-mail-addresses. So nothing too fancy, just a way not to code everything needed for registration yourself.
• Feed fetching has some history, cato rewrote it from the original and mk-fg rewrote it as a django management command, as far as i see both with python requests and parallell fetching. I did not rework anything of it and did not see the need, yet. I would probably rework a bit of it when finally cleaning up for a pep8 compliant code. If you want to work on it, feel free to improve it. I would not make it too complicated. I do not see what you want to do with machine learning there.
  • Seperate apps for optimized fetching may be possible by just using the same db.
• I am more of removing some overly complicated stuff to make the code more readable and portable (i.e. to newer django versions) at the moment. Adding UI will come for having a multi user feedreader and a multi-site planet.
  • I do not understand what you mean with using it more as a library. This is a planet software primarily not a feed fetching library?
• I removed the tag cloud, because it seemed broken here and looked like it would be easier to re-do it some time instead of fixing it, especially because it relied on some of the stuff i am trying to simplify. I think i can be re-added, best with some django-tagcloud package or similiar.
• For the UI the plan was to get the template to something with a reactive layout, cato suggested based on foundation, i used bootstrap for some stuff. I am really not an UI designer, so this comes after the things i like to do ;-).

[allo-]

@mk-fg Keep your repository as it is, it's fine there. Adding a note, that you're not actively working on it will be useful. I just started again to work on it, after i migrated my old installation to your fork (which already added some stuff i always wanted to have) and then started with this basis to add stuff for my personal reader.

I had no intent to make an official version, but on the other side i do not add features which are just useful for myself. My plan is still to get it as planet/feedreader system with the option for someone to host it as web service. A looong time ago cato and me had the idea if we could make a replacement for the discontinued google reader, as both of us used feedjack in the past as personal feedreader.

I do not know how many users are still using feedjack and would update, but i guess it would be more fair to create a new pypi project anyway, as the upgrade path from a very old version isn't that easy and nobody should be surprised when he does an upgrade of the installed packages. Anyway, if i think it's useful i will ask then.

[mk-fg]

guess it would be more fair to create a new pypi project anyway

Yeah, I think github had exactly right idea with having "user/repo" as project id's, so that switch to a fork wouldn't happen automatically.

upgrade path from a very old version isn't that easy and nobody should be surprised when he does an upgrade of the installed packages.

True, and in retrospect, probably should've done that with the pypi "feedjack" entry that was there before my fork, too.

Anyway, if i think it's useful i will ask then.

Sure, no rush.

I had no intent to make an official version

I think only issue and a source of confusion here is "official version" phrase, which isn't useful in the context of this project.

There're lot of more specific and useful designations, e.g. "version with most features", "version on pypi", "mk-fg/feedjack", "version for latest django", "version from original author", etc - which actually mean something, and don't require long and pointless explainations, so maybe ditching "official version" entirely would be for the best ;)

[COLABORATI]

Thanks for your discussion! 'Official' version of course is meaningless, features and dev status are of interest. I will watch and play around, thank you very much for your attention!