RFC: myTitle and myDescription fields in subscriptions

[scripting]

An idea came up in discussions the other day with @cagrimmett and it's a good one, something I've wanted for some time.

Motivation

Sometimes people give terrible titles to their feeds. For good reason, they can't visualize a context in which the title will appear, or the context they've come up with is too narrow. For example the other day I found a feed with a title that begins with a newline character followed by a tab. I can't imagine what provoked that, but it sure screws with the sorting algorithm in FeedLand when you want to view your feed list by title.

So the idea is this -- allow the user to give the feed a new title. And while we're at it, let them give it a new description as well.

The design

1. Add two new columns to the subscriptions table, myTitle and myDescription, initialized to null.
2. To change the title or description, click an edit button next to each in the Feed Info page for the feed. An ask dialog appears, and the result is saved in the subscriptions table record for your subscription to that feed.
3. When an item from the feed appears in a timeline or in your feed list, or when you're viewing the Feed Info page for the feed, your title and description are displayed in place of the one from the feed.

Possible problems

1. If you unsubscribe your changes are lost.
2. Should your title and description appear in your OPML subscription list? At first I thought yes, but then I considered possible abuse. It's better if it becomes feedback for the source of the feed.

Why it can't be done now

I did an investigation into how this would be implemented, and the problem is that when FeedLand gets information about a feed internally it doesn't carry with the call any info about who the user is that it's being made on behalf of. And that function is called in a lot of places at all levels in the code. It would require significant change in how it's called.

This means what seems like a small feature would require a lot of careful work, I'd say it could be done in a week, and right now that's not feasible. Also the chance for breakage is high, and it's a stressful project, which isn't something i'm feeling like doing now (trying to get out of that mode, been doing it all year this year).

And that's not the only function that needs to be modified, just the most central one. :-)

[scripting]

Good thing I didn't close this, because overnight I came up with a very low-tech solution that can later evolve into the complete one that I explained above.

The idea

1. Same UI as before. There are Edit buttons on the Feed Info page for the feed, next to the title and description. Click the button, a dialog appears asking what you want the new title/description to be.
2. When you click OK, we update a table that's already in memory (more on that in a bit), it has three columns, the URL of the feed, your new title for the feed and your new description for the feed. We call the server to save that table.
3. This table is not saved in the database, it's saved in a new file we keep for each user called feedNames.json.
4. When we load the page, we get feedNames.json, and create a new macro called <%feedNames%> and store the JSON we got from reading feedNames.json.
5. In the source for feedlandHome we include a new element of appConsts called feedNames whose value is <%feedNames%>. Thus appConsts.feedNames will always be available.
6. In a few key places where we display the names of feeds, we do a substitution through this table. This part is more hazy, not sure all the places that have to be considered but it will be factored to be a single call, so it will be easy to add, presumably. If there are places where the old name is visible we hope to find them by using the product, and hopefully people will report these as bugs.

This may sound like a lot of processing but it really isn't much. It will add a small fraction of a second to the rendering of feedlandHome on the server. It will add some overhead even for people who don't use the feature, when we look for feedNames.json and don't find it. Is it worth the cost? I think it might be.

[cagrimmett]

Would it be worth modifying the importer to allow for myTitle and myDescription to be set via import if the attributes are in the OPML file?

[scripting]

Would it be worth modifying the importer to allow for myTitle and myDescription to be set via import if the attributes are in the OPML file?

Probably. But I didn't want to go that far without thinking it through, concerned about abuse.