progress on rationalising file attachments API vs TTW ( a podcasting pre-release issue :o)
13-July-2005
permalink trackbacks (1) email thisSteve has spent a lot of time and effort implementing the blogging APIs for KNotes, and done a great job of it: us authors can happily move between API clients like ecto and through-the-web (TTW) editing in a seamless way. But there are some aspects of our functionality where the API is just fundamentally so different from the web interfaces that issues spring up. One of those is the following:
- If I attached a file through the API, it ended up in the blog_mm foldr for the weblog the entry is in.
- If I attach a file through the web interface, it is created directly within the weblog entry as a Zope container object.
Why? Because of the way the API sends the files up to the server. From the client's point of view, it needs to send the files up before it can post the entry in which the files appear: until the server gets back to it, the client cannot know what the URLs for the attached files will be. So when an API client posts and entry which has a file attachment, it first posts the attachments. But this means that when our server-side of the APi gets the request to create the file attachments on the server, it does not yet have a weblog entry to put them into! Thus, we decided to follow blog-publishing practice and stash these in a folder called 'blog_mm' inside the weblog object.
But in our through-the-web interface, it makes much more sense to create these files directly inside the blog-entry object. Again this is a fundamental and natural consequence of the way Zope works and the way weblogs and web interfaces work.
OK. We have file attachments in two different possible locations. We also have information about them in an SQL table to enable very fast rendering. But that meands that every time we write a render we hav two cases to take care of. Ugh! For instance, requests have been coming in for some of that podcasting stuff everyone's been haring about. Easy-peasy - except for the two-faces-of-attachments :o)
So - yesterday Steve implemented a system on our test server which moves files from blog_mm into the weblog object when an entry is posted via the API. It was tricky ( don't ask :o) but it works. So we can now attack all the render efficiency issues in a clear an simple way. One such issue i to deliver file enclosures in feeds - RSS-2 and/or atom. That will be quite easy now; the only issue is that RSS-2 apparently only allows one enclosure, which mean that the natural approach ( any file attachment becomes an emclosure) will not work. We'll post sometime soon with news about which way we fell on that issue, and about how to podcast with KNotes :o)
1 Trackbacks (links from other content)
1 Knotations entry on planned podcast support
Linking and trackbacks
When linking to this weblog entry, please use the 'permalink', which is http://www.knownet.com/Members/mmalloch/blog/entries/2617057958
