NewFeatures: Recent Entries For 2005/09

2005-09-24

HttpsUrls

New: https:// now supported in plain text

As part of fixing Atom feeds to not break embedded https:// urls, I decided that we should support plaintext https:// URLs, like say https://bugzilla.redhat.com/.

DWiki should now support non-HTTP URLs much better in general (before, there were a number of problems and issued). You can even include mailto: links if you really want to.

Written 00:00:43 by cks.

2005-09-15

SyndicationDiscovery

New: Atom feed autodiscovery

There's a standard for autodiscovery of Atom feeds, involving <link rel="alternate" type="application/atom+xml" href="..."> element in your <head>. Now DWiki has a atom::autodisc renderer to create them.

The current code only generates 'recently changed pages' Atom feed links, and so disappears entirely when there isn't one. In theory one can have multiple autodiscoverable feeds (the first is the default, and they get title="..." elements), but I don't quite feel like being that daring just yet.

(I am also not confidant that clients have the UI issues involved sorted out. I'm not sure I have the issues sorted out; for example, should file pages have only the comment feed in the autodiscovery, or should they also have the recent changes for their directory feed in? Which better matches practical user expectations? Can I expect users to be aware of the difference between directory pages and file pages?)

Written 01:11:41 by cks.

2005-09-14

LinkToComments

New: linktocomments renderer

This is a little new renderer that creates a link to a page in the view necessary to show comments. In turn, this has caused the 'your comment has been posted' template page to be tarted up so that it uses it, thereby letting people who have posted comments see them in the page they go to.

(I have decided not to have it link to the comment section of the page, just on general principle. I may change my mind about this.)

Written 15:39:37 by cks.

2005-09-12

FeedMaxSize

New: feed-max-size and feed-max-size-ips

This is all because LiveJournal has undocumented size limits on incoming syndication feeds, limits that DWiki can easily blow past. Since I actually wanted LiveJournal to be able to get syndication feeds from me, DWiki has grown two new configuration settings.

feed-max-size is an integer kilobytes. It is a rough limit on how large any feed can be; once DWiki generates a feed that is this many kilobytes or larger it stopps adding more entries, regardless of the setting for atomfeed-display-howmany. If unset, there is no size limit.

feed-max-size-ips restricts feed-max-size to the whitespace separated list of IP addresses or tcpwrappers style IP address prefixes (eg '66.150.15.' to get all of 66.150.15.*). Syndication fetches from other addresses will behave as if there was no feed-max-size.

Strictly speaking, feed-max-size limits only the size of the atom::pages or atom::comments output to that size. Whatever else is tacked on to make up a feed (hopefully not very big) will add some extra size.

Moral: undersize feed-max-size a bit. For LiveJournal, the limit is apparently 150 kilobytes (currently), so setting it to '120' or so should provide a comfortable safety margin.

Although I'm not entirely fond of this (to put it one way), the documentation has been updated appropriately, making this feature more or less official.

Written 00:39:49 by cks.

2005-09-03

OldestVirtDirs

New: /oldest/ virtual directory restriction

DWiki has long been able to give people the latest N things in a virtual directory context (as latest/<N>). Now it can give them the oldest N things, using the obvious syntax: oldest/<howmany>.

Just to show off, ranges properly convert themselves into 'oldest/<N>' at the end of their run, just as they convert themselves into 'latest/<N>' at the start.

Documentation has been updated appropriately.

Written 01:19:40 by cks.

BetterLastModHandling

New: Better Last-Modified handling

Over the past while it has become increasingly obvious that it's useful for as many responses as possible to carry a Last-Modified: header. (The last straw was wanting Google's index to show modification dates for DWiki pages.)

My reason for killing Last-Modified: was so that things like logging in and logging out, which can't be reflected in the timestamp, would still have conditional GETs be served new pages. But since the conditional GET logic is in DWiki itself, I can have DWiki be smarter about it.

DWiki now separates the page timestamp from the idea of whether the page timestamp is reliable or simply vaguely useful information. The page timestamp will always be served if it exists at all, but conditional GETs only look at the page timestamp if it's reliable (which means that if authentication is on, the answer is generally 'not').

This should work much better.

Written 00:40:54 by cks.

This is a log of new features of note in DWiki.

This is more text, so that we will run down the side of the page and I can see if things collide madly as they probably will. I hate layout.

(Previous month | Next month)
By day for September 2005: 3 12 14 15 24; before September; after September.
Page tools: See As Blogdir, See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.