Atom feeds

[jdpage]

Provide Atom feeds for:

• [x] sitewide edits
• [x] page edits (see #15)

and make sure to expose them as

• [x] in-page anchors on the entry
• [x] in-page anchors on the html edit list
• [x] header links on the entry
• [x] header links on the html edit list

[woodrowbarlow]

it would be cool to have one feed that covers multiple things based on the url. for example, if i subscribe to jonathanwiki.net/feeds/user:woody+page:65.xml, my feed would contain my user mentions plus edits to page #65.

Also, maybe feeds could be embeddable in wiki pages? So I can embed my feed on my user page?

[jdpage]

1. I'm contemplating adding a page-include syntax that lets one include the entire contents of another wiki page into a page. Useful for stuff like categories; if you've looked at those pages, you might have noticed that they all feature the same text at the top.
2. That said, I may implement feeds as a separate script, which would throw a wrench in that. I dunno. I'll keep that in mind as I implement.
3. User pages aren't actually special pages! Following a page gives you all edits for that page and all mentions for that page. I could mention the main page just as easily as I could mention your user page. Which makes your proposed URL even simpler: /feeds/woody+65.xml

[woodrowbarlow]

does slash-delimited namespaces break the idea of combining feeds with a custom url?

[jdpage]

Well, everything after the /f is parsed by the script, so there's no technical reason that it would...

Options:

1. Just use the slashes: /f/65+User/woody.xml. Advantages: easy to implement, obvious solution. Disadvantages: it's a really goofy URL, breaks the semantics of both + and /.
2. Replace the / with another character not allowed in titles, like a hyphen: /f/65+User-woody.xml Disadvantages: counter-intuitive as all get out, means that you end up with /f/User-woody.xml for the single case instead of /f/User/woody.xml.
3. Urlencode the slash: /f/65+User%2Fwoody.xml. Advantages: probably the most technically correct. Disadvantages: ugly single case: /f/User%2Fwoody.xml
4. Change the syntax entirely. For single feeds: /f/User/woody.xml, for compound feeds: /f/.xml?include=65&include=User%2Fwoody. Advantages: probably also the most technically correct, keeps the obvious syntax for single feeds. Disadvantages: now there are two ways to get the same feed, which is gross.
5. Drop the entire concept and use an external feed-aggregation service.

[woodrowbarlow]

if you want my opinion, i like option 4. i think option 2 is also okay-ish, although i would use colon.

[jdpage]

Is this still necessary, though, if I implement the [[syndicate:...]] tag (#23)?

[woodrowbarlow]

i guess not. are you thinking of eliminating the idea of feeds altogether?

[woodrowbarlow]

the only thing i can think of is that, like with the rementions, relying on syndicate links as a subscription mechanism forces users to not have full control over what they are subscribed to (i could add a syndicate link to your user page as a spammy action).

[jdpage]

No, feeds are definitely going to be in. Just reconsidering the idea of aggregate feeds.

Honestly, so much of this software is structured around social policy over software policy that this one thing isn't really any more of a concern than then thousand and one other spammy actions one could take, e.g. repeatedly editing a page that you're subscribed to, repeatedly mentioning you, repeatedly editing your user page, etc. It can be handled the same way as all of those: by banning the offender.

Also, it could be advantageous to have the ability to tag someone in more permanently, if used very judiciously.