You are looking at the HTML representation of the XML format.
HTML is good for debugging, but is unsuitable for application use.
Specify the format parameter to change the output format.
To see the non HTML representation of the XML format, set format=xml.
See the complete documentation, or
API help for more information.
<?xml version="1.0"?>
<api>
<query-continue>
<allpages gapcontinue="Removed_Database_Tables" />
</query-continue>
<query>
<pages>
<page pageid="144" ns="0" title="Reading Page Wishlist">
<revisions>
<rev contentformat="text/x-wiki" contentmodel="wikitext" xml:space="preserve">[[Category: Wishlists]]
* http://community.livejournal.com/suggestions/818998.html - Filter page to display only entries with certain security levels. [In DW Suggestions]
* http://community.livejournal.com/suggestions/779609.html - Hide/Unhide Post option that would conceal a particular post behind a link when you view your Friends page.
** [http://dw-suggestions.dreamwidth.org/40350.html In DW Suggestions]
** http://dw-nifty.dreamwidth.org/3415.html does this
* Related to above - an "unfold" option next to cut-tags, so they can be opened and read without having to navigate away from the reading page. Similar to the "add cut unfolders" option in the LiveJournal Firefox add-on (https://addons.mozilla.org/en-US/firefox/addon/4536), which adds a little plus sign next to the cut-tag text that you click to expand (https://addons.mozilla.org/en-US/firefox/images/p/14694/1182418813).
* http://community.livejournal.com/suggestions/761458.html - easy way to read Friends page from oldest to newest.
* Mentioned in above suggestion and elsewhere - a bookmark that lets you pick up where you left off on your Friends page.
** http://dw-suggestions.dreamwidth.org/64366.html is a similar thing in DW suggestions
** http://dw-suggestions.dreamwidth.org/48201.html may also be useful to people who want this
* Ability to filter out certain user/tag combinations (e.g. "don't show me anything tagged of Joe's tagged ''rant''").
** Done with the new subscription filters
* Keyboard shortcuts to navigate back and forward through reading list entries.
* The ability to set default view to filter out certain journals or communities on certain days or times of day (e.g. "don't show me community X on Thursdays" or "don't show me community Y during work hours").
* http://community.livejournal.com/suggestions/790275.html a single e-mail summary of a user's LJ posts.
* Instant notification of new entries on the watchlist not with emails or similar, but: a) either a little message in the navbar that appears *without* reloading the page (so I only need to reload when I see there are new entries) b) as a clickable link that opens a new small window which checks for updates every 5 minutes or so and gives a notification if there are new ones. This prevents users from reloading the page again and again and again and does not make it necessary to track everything. Could be a paid feature. Preferably works for filters, too (so I can choose to only see when my filter x is updated). Semagic once was able to do something like this.</rev>
</revisions>
</page>
<page pageid="453" ns="0" title="Reading page RSS">
<revisions>
<rev contentformat="text/x-wiki" contentmodel="wikitext" xml:space="preserve">[[Category:Brainstorming]]
Following discussion in IRC about whether an RSS version of the reading page is something we might want to offer:
==Pros==
* It's something people have asked for before, and would be an extra way for people to interact with site content.
** The former is not a "pro"; someone asking for something doesn't influence its goodness. -xb
** The latter is true, but is that good? We could also add a telnet interface, or raw DB access, and those are "an extra way for people to interact with site content" but I'm sure we'd both agree they're bad. -xb
* Could potentially be use full in cross-site integration.
** Yes, potentially, but I'd still be scared of the load this would cause to have federation rely on RSS feeds. -xb
* If we have a proper RSS version of our reading page, we'll be able to do it ''right'', as opposed to the custom style version that some people currently use on LJ.
** I don't feel a burning need to implement something just to do it "right" or demonstrate to others that they're doing it "wrong". -xb
* In theory, serving RSS should be less bandwidth intensive than serving HTML.
** This presupposes that users load it less. Given how automated an RSS feed will tend to be, I'd argue they will end up loading it more. Could be wrong, though, I have no evidence to support my claim. -xb
Overall, the list of "pros" seems pretty thin to me... I don't really understand why people want this feature, what they intend to use it for, why it's better than the reading page, and how it will overall benefit the community of DW. -xb
==Cons==
* Concerns about ownership of content and the owner retaining control.
* Might encourage people to put their feeds with authas details on public, web-based feed readers.
** Easy enough to work around, we can solve this. -xb
* If the security setting of an entry is made more restrictive, a version grabbed from the feed may persist longer than the author wished.
** This "problem" exists with the reading page in general and isn't unique to this feature, so I wouldn't list it here. -xb
* In practice, people having feed readers automatically polling the site every 30 seconds could lead to increased site load.
** We can rate limit pulling the feed relatively easily, so if usage does become a problem, we can solve it. Or restrict to paid users only, too. -xb
I would also add:
* Breaks down some of the community aspect of the site by potentially discouraging participation by isolating users from the site. -xb
* Feature becomes nearly useless if we allow content owners to say "do not allow my content to be aggregated". (Would you really use an RSS Reading Page feature if you knew that 50% of the posts on it would require you to click back to the site to read?) -xb
==Possible implementations==
Any one or more of the following could be used to try to minimise some of the potential problems.
* Have the extent of entries showing up in reading page RSS feeds be settable in the same way that they are for entries in the recent entries RSS feed. That is, allow full entry, summary only, title only or (possibly) no entry showing up at all. This could be either based on the same option as for recent entries, or it could be possible to set the two individually.
* Make it so the reading page RSS works ''only'' if authas information is provided. This would cut down on the potential for entries to end up splashed around the web with ambiguous or no authorship attached, but could increase the likelihood of people accidentally leaking their passwords/other people's entries where they shouldn't be.
* Have a delay time between an entry first being written and the entry appearing on the feed. This could give time for any "oops" moments and quick editing of security before the entry appeared on feeds. It could also be used to limit the frequency with which the feed would update, thus negating the risk of feed readers spamming the servers, somewhat.
* Extend the default RSS specs to include more extensive per-item author information, to try to ensure that authorship information always remains intact. Extensive metadata would also be useful for cross-site integration.</rev>
</revisions>
</page>
</pages>
</query>
</api>