In my occasional looking through the oldest issues in Trac, I came across High-level feed framework should make more feed elements available. I vaguely remember looking into this some (apparently 7) years ago thinking it wouldn’t be too difficult, recoiling at the number of possibilities, and instantly giving up.
I love RSS and friends. I really do. Unfortunately the internet at large does not so much these days. I haven’t had a job that required me using the syndication framework in… a very long time. I think I am not alone, and because of that the syndication framework is unlikely to get attention from contributors, given what I see as the difficulty for new contributors to get started.
So I think the syndication framework would do better outside of Django, maybe in django-commons, where it could (perhaps) get a bit more attention in an easier to contribute space. It could also go there to die. I’d prefer the first but to be honest I’m also okay with the latter, as long as there is some nice easy way to do RSS, I’ll be okay.
On the other hand, it’s not that much code to maintain, it works, RSS isn’t going to change, the maintenance burden is small, it isn’t really hurting anyone, people will need to change their code and we’ll cause unnecessary churn, and all those other usual arguments.
But I am interested in what other people think about this.
I’d be -1 on removing syndication. Django is meant to be batteries included.RSS feeds are an important part of building fully featured web sites, they’re an important tool in the open web, and it’s a major strength that Django provides this. Much like sitemaps.
I think a better idea would be to provide a blog starter template, as part of the “improve startproject” effort, and show the syndication framework in action for newcomers.
I frequently use the syndication framework in my projects so wouldn’t want to see it relegated to be outside the main Django code.
While RSS/Atom feeds aren’t as popular these days in terms of the percentage of sites they’re available on, they are still used a lot.
I’ve never liked the syndication framework tbh - I find its structure very confusing to use - but I wouldn’t want it to go.
Perhaps a better solution would be to find a way to make it easier to make some progress on that ticket (and any other syndication related ones?). Break it up into smaller, more comprehensible pieces of work?
I think it’s important to keep this library in core.
For beginners or anyone starting a blog, having syndication built-in is really useful. It makes Django feel “batteries included” and lowers the barrier to entry.
Even experienced devs benefit because they don’t need to install and maintain a third-party package just for RSS/Atom feeds.
Removing it would make Django less complete for content sites.
But I wonder… Are people really clamouring for the webMaster or managingEditor fields? Is there any point in supporting cloud, rating, textInput, which are all dead and nobody can even use?
For Atom, the picture is a bit worse, because we likely do not want to put the effort required into supporting things like, atom:source, per-element xml:base and xml:lang (or do we?), and we likely don’t want to deal with all the footguns present in type="xhtml".
So the point here: how do we decide when we’re done with these and can put a pin in it? Maybe it’s as simple as we’ll know it when we see it.
And the larger point of course, how do you know when anything is “done”, or “done enough”, I will leave to your own musings.
We could wontfix these tickets easily enough. That they’ve not been implemented implies a lack of demand, one might think. (A wontfix can always be reversed if a PR turns up)
Then, separately, if someone wants to take on “Refresh the syndication framework” as a DEP, I’m sure that would be wonderful too. (I don’t think providing a migration path, including “stay as you are (with minimal tweaks)” would be too burdensome.)
Personally I have never used this part of Django, so I could possibly say +1 to removing it, however I have typically built what I would term “web applications” (mostly private pages with a logged in user) with Django compared with a public website (publishing public content or a marketing site for an application). As Carlton mentioned above, I could see this as a possible good question to ask users when they start a project to direct them to enable certain optional features that Django provides.
Given the prevalence of wanting to keep it, and the later 2 messages from Tom & Carlton, I wonder if we could state that the Syndication framework is “feature complete” in a similar manner to how DRF is considered “feature complete”. This process could potentially applied other parts of Django if necessary. I would see the need for a DEP to reverse this decision. I thinking this might be a help to the fellows, with another route to close off tickets unless they are to do with new python versions etc?
Hey @nanorepublica, I don’t really see any gain… There’s only ≈5 open tickets on contrib.syndication. We could close a couple, sure, but it’s not a big burden. But if someone turns up with a good proposal, we don’t want to put barriers up to ideas. (Most of the current Steering Council were elected on manifestos of doing exactly the opposite. )
I think it might be worth stating, because maybe folks don’t quite know, but DRF required freezing because essentially every change had become a breaking change for the install base.
To give a concrete example, everybody can agree that certain serialiser behaviours in DRF are, lets say, foibles, but folks have built around those behaviours, and so the constant stream of tickets to change those behaviours “for the better™” can’t be progressed.
DRF usage level, maturity, and API surface area make it sui generis within the Django ecosystem. I think taking it as an exemplar would be a mistake.
Fair takes Carlton, this was my typical throwing an idea out there and seeing if it sticks, especially if some small part it reduces the capacity issue we know exists. Starting with syndication creates a precedent for other parts of the framework, if and only if it were desired. I am definitely not qualified to speak on this, but having an option available might be good?
Whether the number of open tickets on syndication is 0 or 5 doesn’t elevate my blood pressure. I’ll do a final review on anything marked ready for checkin, and I’ll fix a regression, and I don’t mind that at all. 5 old tickets aren’t hurting anyone. My $0.02.
)