A bug was squashed: items were not having their reply-count incremented when replied to :o(

Amazing that we did not discover this sooner - it snuck in more than a week ago, downstream of another change. New replies were not being displayed in the weblog views; turned out that the sequence of events after the reply was submitted was asking an RDB row to be counted before it was added :o) FIXED

A cool if small addition to the RSS 2 feed : a comments node for quick replying from a newsreader

The RSS 2 spec permits a <comments> sub element of item. The semantics is a bit confusing (confused?), since it seems to be expected both to display existing comments and offer an affordance for adding a new comment. I guess this is because in most weblogs, these are conflated. I was hoping to allow a very quick an simple add-comment affordance, but obvious that would not suffice for viewing existing comments. But on consideration, our fast_folders view does an excellent job of meeting both requirements: displaying existing comment threads and offering a quick way to add a new one. So the RSS 2 feed now has a comments element in items, which is rendered by NetNewsWire as a link. That link opens fast_folders view, which is a pretty quick way to either add a comment (using the toolbar and javascript-enabled quick editor) or browse the comments thread from that item

Another quite subtle bug was squashed: threads for sending trackbacks were sometimes getting ZODB read conflicts

Steve spent a long time with this one today. Started with the simple sent-trackbacks logging request. Led to him discovering that some trackback threads had met with the dreaded read conflict. We had been passing objects to threads, which in hindsight was a bit naive. Steve has come up with a more sophisticated and much more robust approach now, and it seems to work.

Added sent-trackback logging, into the ZOPE events log andf into the sending objects

(In local server only at the moment) A log of the events performed and error messages recieved while sending trackbacks is now kept. The sending content item also has a property which is tuffed with the sent-trackback-attempts log for its own links (we have decided that the 'sending object' is not the KNLink object when it is used for TTW trackbacking links, but the 'real' content containing it - this of course is also the object whose URL is sent with the ping as source URL ... see below )

Corrected the 'source URL' for TTW KNLink generated trackbacks to point to 'real content' instead of the link object

Somehow this had slipped through the cracks ( not helped by the fact that all of us are avid TTAPI posters, not TTW (Through the API vs Through the Web :O). In through-the-web editing, trackback-enabled links can only be made by striking a KNLink object ( in TTAPI editing, any links in the body or extended are scanned and turned into trackbacks - much much more convenient :O) The TTW created KNLinks were initiating trackbacks which linked back to themselves, instead of to the conent they are part of. This maent that visitors to other sites linked to by a discussion item who clicked on the trackback link found themselves looking at the viw template for the link - confusing and frustrating. We're almost finished rationalising this. The behaviour we have decided on is:

Link made in:

KNBlog or KNDiscussion

Use the blog entry or discussion item as source URL, and the Weblog as the Blog Name

SideBar or Nav links in a weblog

Use the weblog as the source URL and as the Blog Name

Plone content

The KNLink class file will encapsulate the logic for handling this. The policy Steve is implementing now is to use the parent folderish object source URL, and the portal title as the Blog Name...

In all the cases above, the tbtitle and excerpt text will come from the same object that the source URL points to.

We also made broad progress on clarifying many smaller issues, but I'm too tired to document those now {been at it for almost 12 hours now :o}