KNotations

sigh...

Auto-detection of the edit API hads been a real pain for us. Clients differ in their behaviour.

And recently ecto, which used to auto-detect the preferred API and access-point for KNotes blogs, now fails. And blogjet, which used to fail, succeeds :O)

... we did not change anything I am aware of, so I suspect these are clientside changes :o{

ANYway, the worst part of not auto-detecting is that the user is not currently given a hint to specify the MT API (Movable Type). The MT API allows some clients - ed ecto - to edit the summary and extended text, pluys other goodies I think. Which makes for more useful content structuring from the editor. We're proud of the work we did implementing the serverside for the API for plone, and it did take work to support those neat MT extenseions - so this is frustrating :O)

So...

1. If you are setting up remote editing for a KNotes blog, and auto-detection of preferences and API access-point does not work, please choose the MOvable Typ APi if given the choice.
2. We should remember to have another look at the way we specify the MT as preferred API in our edituri text
3. It seems likely that whatever is preveting ecto from noticing our preferred API might also be the culprit in preventing it from auto-detecting the API attachment
4. Andin the meatnime we ought to add some text to the 'set up external editing' content to explain why the MT APi is better.

... of course, once KNotes becomes well-known by the developers of the clients, these problems start to become theirs as well as ours :O)

Sigh... I really didn't want to have to spend the time to implement this, but we decided it was made necessary by the nastiness of some of the trackback spam we've been seeing.

There is now a property in all KNotes weblogs, as well as a sitewide setting in the tool itself, for controlling whether trackbacks need approval before they are displayed. By default, this is set so that only approved trackbacks display. We will shortly be providing a weblog properties interface for managing this and other properties at the weblog level. The sitewide property is set through the tool in the ZMI - kndiscuss_sql (KNotes Config Tool). The sitewide property is acquired if the weblog property is not set.

There are new interfaces for moderating and managing trackbacks. See the screenshot for an example of the manage-trackbacks TTW (through the web) interface. If there are pending trackbacks, managers will see a portlet (in Plone content) or a sidebar (in KNotes content) for Managing Trackbacks. The number of pending trackbacks is listed there, along with a link to the TTW management interface. The manage-trackback RSS feed noe includes an indication of the workflow status of each item. We'll be adding links from there directly into setting the status - currently there is a link to delete each trackback but not for approving or rejecting. We'll also be adding interfaces for managing trackbacks wherever they are displayed ( in detail views, sidebars, portlets and plone-content comments views); and will also consider an interface for non-managers to report offensive trackbacks.

By the way - We've also been making a lot of progress on other aspects of KNotes recently, but that will have to wait for another entry here :O)

This is just a test of del.icio.us playtagger - the new shared javascript from del.icio.us which enhances mp3 links with a lightweight flash object to play the audio, streamed, in the browser, in your page. The enhancement also places a tag-me link to post the mp3 to delicious.

This could be a great way for ordinary endusers to get the best of both podcasting and in-page playing: posting mp3 files is the open, standards-based way to share audio, allowing real RSS podcasting, permalink-sharing, user-timed listening etc. But some authors like the in-page feature that an embedded flash object provides, and seem unaware of the advantages of simply posting mp3's from the user's point of view. For an example of audio which will play in the page via Flash, but otherwise cannot be used, see this page of 'podcasted' interviews

If this little delicious shared javascript trickery works, it should mean that just attaching an audio file to a knotes blog post makes it playable in the page and usable as a file if the user wants to save it, link to it, or subscribe to podcasts.

I'm attaching a little audio file: please forgive the copyright-busting; if you enjoy it, do by all means look Catfish Keith up and buy some CDs :o)

If this works, you should be able to do streamed listening to the audio attachment (see above for the link - it should have a little arrow nexk to it, like a forward button). I may have to change some templates to get the script include into the head; for this example I'm first trying the script include in the body of this message. I looked over the 3289 bytes of the include and it does not look to me as if it needs to be in the page header.

I'm about to post a short overview of our plans for dealing with trackback spam, and realised that before going into those measures, I should first review the behaviour - current and planned - regarding authenication for RSS/atom in KNotes.

First - what is the issue? Basically, manegers can use the permissions form for a KNotes weblog to make the blog readable only to certain members. Likewise, a parent Plone folder could have been given a workflow state of 'private'. In either case, through-the-web pageloading requires authentication by a member with the correct permissions.

But what about the RSS/atom feeds for that private, members-only weblog? If a snoopy and savvy person wanted to type in the url for an RSS feed for the private weblog, surely they should not be able to read content in their news-reader which they could not read in their browser?

No, they should not. And at least some news-reading clients respect that. For instance, NetNewsWire offers username/password properties for a subscription, and will present an interface for entering them if the subscription demands it with its http response header.

And KNotes' RSS and atom feeds will not return content unless given an appropriate username/password when the request is made on a zope object which would require authentication for viewing through the web. Try it... if you subscribe in netnewswire to a private weblog, you'll have to enter a username an password ( in the get-info dialog for the subscription ) in order to fetch content.

BUT there is still work to be done:

Demand authentication nicely

We need to have the private feeds send back an authentication demand header rather than the error they currently do. This is a very small job but needs to be scheduled,

Return '' for nested private content in public feeds

More important by far: If you subscribe to a KNotes feed with '?include_discussion=1' -- ie you want to get nested content in the feed -- you can read nested private content. At the moment, privacy is only 'ert' at the level of the object the feed is called on. The content of the feed is assembled with an SQL query, so zope-wise permissions are not taken into consideration when grabbing the item content (and we definitely want the SQL speed). What we need to do is to impose a very simple policy: content which is not public through the web should not appear as nested content in any feed.

This policy would be draconian but safe. The SQL database kndiscussion table rows can 'know' whether or not "some" authentication is required (but cannot of course encapsulate zope's complex acquirable permissions, so cannot know whether the current request should authenticate against a row). But, since a row can know that its content is not public, it can have its feed content an empty string except when called directly on its parent object... in other words, a different query would have to be called for the non-nesting case

As you can see, some changes to the SQL data model are required in order to prevent non-public content from appearing in feeds other than those called directly on its parent. That means work, and will have to wait.

In the meantime, beware that private content could be sniffed by savvy snoopers. Personally, I would resist privacy anyway, but I appreciate that it is very important to some of our own users - and we will attempt to effect correct behaviour soon after 'release' :o)

Those who follow this blog know that we've been planning to expand the range and features of the syndication feeds from Knotes content. The biggest priorities were:

filecasting ('podcasting'... doc-casting)

- delivering file attachments as enclosures ready to download directly from a news reader. In the case of audio or video files, this is usually called 'podcasting'

'full' content feed

Many users now prefer to experience web content almost exclusively through their newsreader of choice; not only reading content without viewing it in a browser, but also invoking editors to bookmark or blog about that content without viewing it on the web. To accomodate this growing preference, many blog publishers now offer 'full content' feeds. In the case of KNotes content, which has a lead-in/summary, main body text and extended-text, we would assume that the extended text should be excluded from 'full' content in feeds, just as it is in our aggregate web views - we'll call this 'full-minus-extended-text' the "main content" of an entry.

RSS 2 support

KNotes has supported RSS 1 and atom formats from its content. We have never wanted to appear to take sides in the atom-vs-RSS contention, but supporting only RSS 1 and atom coiukd appear to be implicit support for atom as the format for future features, since RSS 1 is ad old format. RSS 2 is the RSS format being developed in the near future and includes many useful features which our feeds have not yet supported - we wanted to include support for RSS 2 from KNotes, and begin to explore support for the new features in it.

On the other hand, we want to avoid a confusing proliferation of choice about which feed a user might subscribe to. We already have a choice whether to 'include_discussion', anfd a choice between atom and RSS-1 - making 4 choices in all - if we delivered the complete range of RSS-1,RSS-2,atom X include_discussion X full-content,main-content,summary we would be giving users a choice of 18 feeds :o{

So we've decided that the RSS 2 feed will be 'the' main-content feed and 'the' filecasting feed. In future we might add these features to the atom feed (which is now beginning to feel featureless :o)

As yet, the RSS_2.xml feed does not support the include_discussion search argument, so is only available for level-one content. We'll add support for include_discussion later today, an then put links into the Subscribe sidebar to expose the new RSS 2 filecasting main-content feed to end users. It displays the lead-in anf the html main body, with enclosures for any file attachments in the entry. If there is extended text, this is clearly flagged at the top an bottom of the feed item (for instance "View full content (18405 bytes more)". See the screenshot.

In the meantime, you can get a feel for the new format either by appending '/RSS_2.xml' to a KNotes weblog url, or by trying one of these:

• SIGOSSEE Project News [main content + filecasts]
• KNotations [main content + filecasts]

Some policy decisions remain to be made - for instance, which of the formats should be the 'one' auto-discoverable feed which we link to from the header? I am inclined to think that the new RSS2 feed ought to be the 'one' that users subscribe to when they click the RSS button in safari, etc. We'll get back to that question later :o)

We've just deployed a new method of handling comments by non site-members. If a comment is submitted 'anonymously', the email address given in the comment form is sent a confirmation email. If the special link in that email is not opened, the comment is not posted (see the screenshot). When submitting an 'anonymous' comment, a user can optionally ask to be registered as a member while the server is at it (by entering a username), in which case the confirmation email includes a server-generated initial password. Both anonymous commenting and joining-while-commenting are under control of site and blog properties. We're aware that some sites may have exotic registration policies or restrictions: in those cases the site manager should turn off the ability to join while commenting at the site level, using the KNotes tool in the ZMI.

I'm now beginning to experiment with having a one-form-fits-all add-comment form rendered directly into the one-entry views (most blogging systems do something like this). That form would cover all the cases: [I'm a logged-in-member; I'm a not-logged-in member; I'm not a member but want to join while commenting; I'm not a member and do not want to join].

We'll still include links for creating 'full-featured' discussion items (with extended text, categories etc), especially in the soon-to-come forums views. Watch this space ;o)

We've made good progress on tools to make trackbacks easy to monitor and manage. By the end of the week, we'll have deployed a pretty thorough suite. In tests on our own content, these make it easy to bash trackback spams almost as soon as they come in.

There are two new through the web templates:

weblog.trackbacks

This is a weblog-specific template which can be invoked on a weblog or any content within it. It displays a batched aggregate weblog view of the trackbacks within that content, with affordances to delete trackbacks if you have manager role. This template will soon become the 'more' link from the 'recent trackbacks' sidebar, and we'll also hav a link to it from the stats sidebar

trackback_admin

This is a Plone template which can be invoked on a Plone portal itself, or on any content within it. It requires manager role. It provides a batched listing of all trackbacks within the content (either flat or deep) with checkboxes for selecting items to delete

There is also a new RSS feed - TBs.xml - which can be invoked on any Plone or KNotes content. It demands authentication by a member with manager role, anf takes an optional limit search argument. It lists (deep) trackbacks anywhere ithin the content it is invoked on. The item display includes links to the content rceiving the trackback, the URL source for the trackback, and - especially convenient - a direct DELETE THIS TRACKBACK link. Clicking the delete link in an item calls the delete script through the web ( and will demand authentication if you are not already logged in ). We have used this feed successfully in netnewswire on os-x but at the moment are not getting authentication to work in the windows readers we've tried. i we annot get this working in a widerrange of readers by the end of the week, we'll change our plan - if so, we'll post a notice here to that effect.

See the screenshot for an annotated anatomy of the special RSS feed.