I'm back!

10-June-2005

Mike is feeling much better now, and has been getting some work done for the past couple weeks.

After a few months of being pretty useless, I'm back at work and getting some things done now!

See the SIGOSSEE standards and architectures WG area for some stuff I did last week, for instance.

Now that I'm back in the saddle, I'll be posting updates on progress towards finalising knotes here.



Mike Malloch; 10-June-2005 05:14:40 forum (0)

i18n progress

15-June-2005

Steve has been converting our page templates to make use of the internationalisation interfaces in Plone

Steve has made quite a lot of progress converting the page templates to use the i18n machinery in Plone. We had meant to do this for ages, of course, but were particularly nudged into it because of the changes recently made to indexFolder which allow users to maintain multiple language versions. It seemed a pity that the content could be in different versions while the user interface strings were all in english :o).

So far, indexFolder is converted and some of the templates in knotes have been started.



Mike Malloch; 15-June-2005 16:54:31 forum (0)

Improved default style in knotes and added some pretty-print utility classes

15-June-2005

The default style in knotes was not using vertical space well enough. It's been improved. We've also added some new utility classes for pull-quotes.

knotes has evolved wuite a bit in the past few months, and in the process the area at the top of the weblog views has come to be rather busy. The default style had not been using vertical space well enoguh to cope with this, so only a bit of the first entry was visible without scrolling.

I had a preliminary bash at improving this at the weekend, and things look quite a lot better I think. I've improved the typography as well, condensing it to get as much content as possible into the vertical space allowed without compromising readability. (Note to self - must add a widget for larger-smaller type :o).

I've also added a couple utility classes in the default style to allow magazine-style pullquotes. See for instance this item in Graham's weblog.



Mike Malloch; 15-June-2005 17:03:32 forum (0)

Batching now works in most knotes weblog views

16-June-2005

We have added batching - fetching items in batches of 10, 20 etc - to knotes. Most of the aggregate views now support it.

Blogs with many entries were beginning to creak under the weight of displaying large sets of entries in some circumstances. We had always planned on implementing a batching system to allow users to view these large sets in manageable chunks.

We've done it! As you can see in this screenshot, Batching Widget the widget allows user to choose which set and what sort-order to view in. Soon we will add the ability to choose the batch size and the level of detail displayed.



Mike Malloch; 16-June-2005 13:21:30 forum (0)

How-to specify new categories from an API client

19-June-2005

Steve recently added a bit of a hack to allow API posts to specify new categories.

Users of knotes blogs who post through the web (TTW) will be used to adding new categories ad-hoc as they post. In the TTW form for editing posts, there is a widget for adding a new category and associating it with the post. (The new category is added to your personal categories - at some point we plan to implementt interfaces for negotiating the promotion of personal categories to blog-wide or portal-wide scoping, but that's another issue. :o)

Users who post with a weblog API client like blogjet or ecto, on the other hand, have had to specify their categories in advance, or edit their entries TTW after posting. There is no provision in the API specifications for creating categories when editing or creating posts: category association is taken to be a list-choice. If a category is not already on the list of categories for that blog (and you as an editor), you have to go to the weblog through the web and add it there.

Graham for one was finding this awkward; Steve has built a workaround. To associate an entry with a new category just insert it between a pair of

'<cat>...</cat>'

tags - anywhere at all within the body of the post.

. When you submit the entry, our API implementation will scan for these 'tags', and any new categories so specified will be added to the categories for the entry. The tags themselves will be removed from the text of the entry when the server processes it.

tags. Make sure of course that you are in a raw-html editing mode when you type in the <cat> and </cat> though - otherwise the tags come through encoded like '&lt;cat&gt;...&lt;/cat&gt;'and are not parsed as 'tags'.

Your client probably can help with this. In ecto, for instance, there is a Custom Tags feature ( on the toolbar, HTML tags in the Window menu, or command-shift-M ). See the attached screenshot Ecto-New-Category . Add the 'cat' tag to the list of special tags there (click the big + icon) and you can even assign it a keyboard shortcut. I just tried this: I added the tag and assigned command-option-c, and then tried adding it in rich-text editing mode...no dice. But in html-editing mode it was fine. The only downside is that the html parser in ecto did not, of course, recognise the tag and so would not let me back into rich-text mode. The ecto parser is not the brightest anyway ( it has trouble with some markup that I use a lot, like definition lists and the cite tag) and since I personally prefer to write in raw html this is hard for me to view as an issue. Just go into html=editing mode 'last thing' before posting, add the categories you want anywhere in the post, and submit. When the post comes back from the server, the tags will be gone but the category will be added.



Mike Malloch; 19-June-2005 23:34:45 forum (0)

KNSin (early development report) plone portal feeds from knotes

20-June-2005

Last week we put together the beginnings of a Plone product geared to providing efficient but flexible aggregations of knotes posts and discussion for use in Plone site content. KNSin will be ready to use in some of our own sites within 2 weeks.

Knotes can deliver RSS and atom feeds quite flexibly and efficiently. This makes it easy for savvy readers to create aggregate feeds in their news readers which assemble content from knotes weblogs and disucssions in flexible and efficient ways.

But a major use for aggregating discussion and weblog content is to use it within the same Plone sites in which the content 'lives'. A common motif in Plone sites not 'built with knotes' is to have the front of site aggregate some content sources, and a few other main site actions display other aggregations: news, events, etc. It is also common to include aggregate summaris in portlets. In our own sites, we have begun to do both of these things using knotes as the source and sql-tool queries instead of z-catalogue searches. This works fine except for two drawbacks:

'Chinese menu' aggregations are difficult
If what is desired is a combination of several sources, then the straightforward method of getting a list of dictionaries with one of the knsql methods breaks down. A more general sql method is needed which can let the administrator define complex aggragations with writing python.
Efficiency
In the straightforward technique, the portal pages display totally up to the instant aggregations, and every pageload triggers an sql search. For fronts of busy sites this is a bad idea and pretty wasteful of resources. We wanted a simple tool that would allow administrators to reliably control the caching of aggregation lists

KNSin addresses both of these problems: It has a simple lines-field property in which a skilled editor can define just about any possible combination of content sources, and it also allows the editor to define a cache-control expiry for the feed data.

For instance, the following specification in the lines-field for a KNSin object asks for all the entries from 3 blogs dotted around the vetnet site, as well as entries from one category in a weblog on another site (the other site is in the same KNSQL database). See the attached screenshot as well

parentuid = 'vetnet/Members/pkamarainen/blog/entries'
parentuid = 'vetnet/collaborate/news/entries'
parentuid = 'vetnet/collaborate/vet-talk/entries'
(parentuid = 'knownet/writing/weblogs/Graham_Attwell/entries' and exists (select 1 from metadata where kndiscussion.uid = metadata.uid and category='Blogging/'))

screenshot of editing a KNSin object If the editor of a KNSin object uses the Update Period and Update Frequency integer fields to determine when data should be refreshed. If a request is made for the data before the expiry duration since it was last refreshed, cached data is returned. Otherwise, the data is refreshed. If no requests are made, nothing happens (the product does not refresh its data unless it is asked for data). The objects of this product's type are mainly intended to be sources of data, but if viewed they display a terse panel of that data. We'll be adapting our indexFolder template to make this a built-in behaviour of indexFolders with embedded KNSin objects. I'malso thinking of makinga knotes sidebar which displays summary listing of any embedded KNSin objects in the sidebar links of a weblog.

Did we have other options? We had thought to address these issues with a pure RSS tool that would digest the XML from some feeds and produce python dictionaries from them for use in portal content. We had too much trouble parsing the XML though, and since XML parsing is expensive we asked ourselves 'why parse xml for data we already have in sql'? KNSin is meant to fill the niche where within-instance data need to be assembled in flexible ways, with rich information about the items for flexible displays (for instance, branching the display based on the dc:source of the items. We had also experimented with literally serving the unparsed RSS items but transforming them in the client and on the fly with XSLT. But this seemed a flakey an inaccessible solution for embedded content ( ie xml data ilands within xhtml content ). One of these days we will write a pure-RSS tool, like CMFSin, but for the time being KNSin is what we need.

We'll be using an early version of KNSin to improve the front pages of the vetnet and NGRF sites quite soon. I'll be back with more news about this later.



Mike Malloch; 20-June-2005 07:25:36 forum (1)

1 comments.

Latest comment:
07-Sep-2005 16:34 by mmalloch; An example of KNSin in action is in my other weblog 'c-Learning'

Some changes to knotes RSS and atom: nice urls; more information

20-June-2005

We've changed the URL formats for RSS and atom news feeds out of knotes, and also changed the RSS item content a bit. The new URL format is shorter and more human-readable. The item content changes add some DC metadata and give better context-of-item information.

We believe in nice URLs here at KnowNet. Unless users will never need to enter them, URLs ought to be both readable and constructible by human beings - consistent, brief and logical. We went to a lot of trouble to make sure that the URLs in knotes make sense. For instance you can type'weblog.archives/2005/05/3' after a weblog URL and know you will get any entries from that day; drop the day or the day and month from the url 'path' and you get the entries for the less-specific date range. (Steve even made it use the month/day format of the locality of the server :o)

Our RSS and atom URLs had evolved a format which was pretty hard to read by humans, so we have changed it. You can now get the feeds by adding simple words to the URL for a Plone or knotes object:

  • [URL OF OBJECT]/RSS_1 - the RSS v1 feed
  • [URL OF OBJECT]/atom - the atom feed
  • [URL OF OBJECT]/RSS_1?include_discussion=1 - RSS 1 feed including discussion as well as blog entries ( atom feeds take the same argument )
  • [URL OF OBJECT]/atom?only_discussion=1 - the atom feed with only discussion items; no weblog entries ( rss feeds take the same argument )
  • [URL OF OBJECT]/RSS_1?category=development/knotes - the RSS v1 feed for items from a specific category (etc...)

While I'm on the subject, we are very seriously considering what to do about offering RSS version 2 feeds, either in addition to the RSS1 and atom feeds, or replacing the RSS1 feed. There are many reasons to do so - podcasting and other file enclosures for instance - but we want to get the basics right from the start so will not be acting for a week or two.

We hav also made some relativelt minor changes to the item format for the RSS 1 feeds: added a bit more DC metadata (dc:source is the weblog or plone container ancester to an item; dc:subject are the categories). We also write in some entity-encoded html formatting for contextutal information about what kind of item it is and in whatr context it was posted - in reply to another item, for instance (in which case it links to that item in the item content).



Mike Malloch; 20-June-2005 07:59:40 forum (0)

You can now get email updates from any knotes weblog

20-June-2005

Steve implemented email updates over the past couple weeks. You can subscribe/unsubscribe to any knotes weblog now, and read or manage 'my discussions'. Members get an email update immediately for every new post in the weblogs they subscribe to. We'll augment these features in the near future, but this should meet current requirements.

While RSS and atom feeds provide a very powerful and convenient way to track many weblogs an discussions, not everyone is comfortable with them. We have had many requests for an email-update facility. Over the past couple weeks, Steve has implemented and tested a system for subscribing to weblogs for email updates. To subscribe for email updates, log in and look in the "Syndicate this weblog" sidebar near the bottom of the sidebars column in a weblog, and click the Email updates... 'Subscribe' link (see screenshot)

how to subscribe to a weblog

. You will get an email whenever someone posts an entry to that weblog. The link changes to 'Unsubscribe' when you are already subscribed to a weblog. You can stop getting notifications by clicking that 'Unsubscribe' link. The emails are sent to the email address you specified when you joined the site; you can change your preferred email address at any time by logging in and clicking the 'my preferences' link in your personal tools link. The screenshot below shows the personal tools links.

When you are logged in, you will see a 'My Discussions' link in your personal tools links (at the top right of the content area of site pages... from a weblog, click on your login name first to see these links). Click that link to go to a page where you can manage (remove) your existing subscriptions and view recent entries gathered from all the weblogs you subscribe to. See the screenshot to the left (click the thumbnail for a full-size image in a new window).

My Subscriptions Sshot

We will be enhancing some of these features in the future. For instance, users may prefer to get 'digest' emails instead of individual emails for every post - they may want 'One Big Digest' email gathering updates across all their subscriptions, or may wan these split by weblog, etc. Users may wan the same power in choosing email updates that they presently have for RSS feeds - by category, etc (see my recent post on available RSS feeds for more on the variety of available RSS feeds. In addition, we have most of the work in place for adding any indivudla entry or reply to 'my discussions' - this would allow users to temporarily subscribe to an entry or reply they are interested in. Another possible future feature would be to hav a persoanl preference for getting email updates automatically to anything that you post.

Watch this space for news on progress towards such new features later this summer. I think the system as Steve has implemented it so far is great, though, and is exactly what our users asked for.



Mike Malloch; 20-June-2005 08:49:36 forum (0)

Plans for 'podcasting' (RSS file enclosures) and RSS-2 support

20-June-2005

We've been doing some hard thinking and close studying-up on the issue of supporting podcasting 'naturally' from knotes. We hope to have file attachments automatically 'podcast' via a new RSS 2 feed-format within 3 weeks

We've been asked several times about podcasting support out of knotes content, but so far have not had an opportunity to do anything about it. Frankly, until recently I was unconvinced about the power of podcasting. But for a while now I have been trying to get the point of it, and I guess I have (see for instance the recent news that the BBC is offering experimental podcasting feeds for some of its radio programming. It has also helped that Al Harris is working on a series of brief interviews on small enterprises and educational technology / open source software; these would make great audio feeds.

It has also occured to me that many of our users post a lot of documents (especially Mico=rosoft Word files :o) - podcasting in the sense of feeds with file enclosure information could be a great way to announce new documents and share them with subscribers.

OK. Sold. What kind of support should we offer? For a start, I do not think we need to proliferate yet another feed option in links from knotes pages. i think that enclosures should 'just work' by default in our feeds, if possible. Second, I do not think that editors should have to specify that an uploaded file should be made available through a feed - all files uploaded as attachment to weblog entries should by default be made available in the podcast feed.

We will be introducing RSS-2 feeds from knotes to support podcasting. We never intended to neglect RSS extension work in favour of atom, so RSS 2 support has been in our plans for ages. We may replace the existing RSS 1 feeds with RSS 2. We need to look hard at backwards-compatibility first; otherwise we will offer 3 feed types as salient links in weblog views: RSS 1, RSS 2 and atom.

We then have a thorny little issue to solve before it is straightforward for all attachments to be detected and added as enclosures. We want to solve this issue anyway for other reasons: at the moment attachments that come through API clients are stored in a weblog's/blog_mm folder, while attachments added through the web are stored directly within the weblog entry. The latter is the best way to treat attachments from the point of view of summarising and aggregating them as resources, and also for managin large numbers of them. the reason we stash attachments added through the API into blog_mm instead is that when the API gets the request to create an attachment the blog entry does not yet exist. We've considered a few hacks around this in the past but never had an urgent reason to do something about it. Now we do.

Watch this blog for news about the solution we come up with, and also for news about the RSS 2 feeds and podcasting.



Mike Malloch; 20-June-2005 08:58:50 forum (0)