Python Desktop Server Weblog 2003/4

Alternative aggregator overview

Update: there was a bug with locked items whose feed isn't in the feed table any more. This is fixed now in CVS and in the current snapshot.

Update 2: there was another bug wich affected the channellist view. This needs to be fixed by changing data in the database. This is done transparently as soon as you view the channellist for the first time.

weblogs.com and non-7bit-chars

So if you use the Python Desktop Server and use your local charset in your weblogs title (or in a category title), you will get errors in your eventlog. It will still work, but you will get errors about not welformed XML.

I can't fix it, as I would have to put in severe hackery into the XML/RPC client code the Python Desktop Server uses - and that's the xmlrpclib implementation.

Some digging provides a clue: it look like it is the pesky non-charset-definition problem again. I get back some methodResponse from rpc.weblogs.com that just doesn't give a charset on the XML definition, and so is interpreted as UTF-8. We had this already.

Encoding all chars as entities isn't an option, too, as in XML only 5 entities are actually defined (lt, gt, amp, apos, quot). All other entities are not valid in XML - you don't need them, you can just use UTF-8 or any charset that you happen to give in the XML definition.

Sigh. Looks like we will have to live with this special problem.

Update: added the stuff like Phil recommends. 8bit chars are escaped as &#xxx; and sent this way to the community server and to weblogs.com. Let's see what that breaks ...

Secret Lives of the Programmer

The dreamtime part of the job is often the most problematic. I happen to have luck in that it mostly happens in my spare time so I often am able to hack away at the keyboard at work time, but there are times where I have to cook up something completely new and then it can keep on spinning the rubic cube for days before I have something ready. And those are the times where conflicts at work happen. I often cover up the internal spinning with other works that only need halfe a braincell, but it's really frustrating.

For example I would like to go for a long long walk when spinning the internal rubics cube, as that helps me the most to concentrate. I can think better when walking. Of course this doesn't work out at a workplace with with time control ...

Don't have a solution for it, though.

Resources for developers

Running PyDS as a central hosted solution?

Short answer: yes and no. There are problems with this, since the Python Desktop Server is always a standalone server process and never a CGI solution. And there is some configuration needed to allow remote access via HTTP that's a bit crude to set up for now. But yes, it can be done. Sort of.

Long answer: How to set up PyDS as a central hosted server

Make sure you use the current medusa version

New beta 0.4.22: fixes to reStructuredText and RSS Feed

One little change that might irritate you: the menu entry Events is now back to the main menu and Externals is down in the sidebar.

Another weblog tool - Kaa

Desktop Servers, Take Two

One important note: all this is not to ditch Moveable Type or other great softeware, it's just to respond to his "why do it that way and not in another way?" question.

First one observation: it's not "Desktop Servers, Take Two" but "Non-Hosted Blogging Software, Take Two" - as the very same problems arise with every solution that's not running on a central host (for example blosxom running in offline mode and uploading stuff by FTP, or the iBlogger stuff where your blog is rendered on your Mac and upstreamed to your iDisc).

The fact that PyDS is implemented as a desktop server and not as a classic application doesn't add to the problems, it only makes some solutions easier.

The fact that PyCS is a community server and not an individual blog solution doesn't add to the problems as other solutions show: there are community server solutions like Manila or Livejournal that provide central access and central editing and still provide community server features.

So the real gripe is that PyDS and PyCS are structured in a way where your blog runs on one machine and the editing tool for your blog runs on another machine. Greg sees a problem with remote access and world-wide editing access being hindered.

But actually that needs not to be the case. There are several ways to solve this problem (two he gives himself):

• run PyDS on your home machine, have a flatrate always-on internet connection and set up remote access (this even works through multiple firewalls, if the firewall admin is cooperative)
• run PyDS on some central machine with static internet connection and set up remote access (this would make PyDS into a central hosted solution much like MT)
• write some tool to link mail to blog or instant messengers to blog, like already is possible with Radio Userland (use the wealth of XMLRPC methods to create postings or other content)
• run two installations of PyDS (or more) and keep them in sync with backup and restore (this might limit use of some tools like for example the ExternalStoryTool and the PicturesTool)

So having your PyDS remotely accessible isn't necessarily more complicated than installing other central hosted blogging software - the only difference is, your blog editing software doesn't need to run on the same host and so the load can be distributed.

Here the fact that PyDS already is a HTTP driven server helps, as I only needed to add remote user authentication to it to enable central hosting of PyDS installations. So yes, actually you can eat the cake and keep it.

reStructuredText problems reported by Garth

Problems with Windows-Version

All fixes will be rolled into a new 0.4.22 as soon as we have all together. We apologize for the inconvenience

RSSFeedRendering.tmpl missing trackback namespace declaration

RSSFeedRendering.tmpl: 1.00 KByte, last change: Thu, 17 Apr 2003 10:01:10 GMT, type: unknown/unknown

click here to download file

New beta 0.4.21: several bugfixes

Due to the larger number of bug fixes, update is highly recommended. Especially the StructuredText implementation is much better now and several problems regarding redndering of URLs in RSS are fixed.

Why a desktop server and not a hosted server?

The main reason why the Python Desktop Server has this architecture is of course that I used Radio Userland before. There were some shortcomings of Radio Userland, that I wanted to solve - mainly the large system resources overhead of Radio Userland (CPU resources and memory resources). I don't like it when a background application takes up more resources than my graphics applications I use to work on my pictures.

But there must be a reason why I wrote this beast and didn't do something better. It's not as if I don't have lots of machines with static internet connectivity availabe - I run my own private ISP and work for company that does ISP solutions as one of their products. So why something weird like a desktop server with replication to another server? Why not something like Moveable Type or any other hosted solution?

One big reason to go the way the PyDS/PyCS combo does is the nice distribution of server load. The community server is just a very simple webserver with some nicely integrated dynamic features. It doesn't need much resources on the server and can handle very large numbers of hits and accesses. The architecture of medusa - the builtin webserver in PyCS - is much less demanding on hardware resources than an Apache would be!

All dynamic rendering stuff is handled at the desktop server and so on the clients machine. This is nice, too, as the clients machine only has to do work when there are postings and not render all stuff dynamically from databases all the time. So it usually just sits there and waits for something to do and doesn't take up resources (hey, this is definitely not Radio Userland we are talking about ).

Another nice thing about the desktop server idea is that the server is always there in the background, even if you are not connected to the internet. You can build tools that communicate via XMLRPC with the desktop server. You can use standard tools with BloggerAPI or metaWeblogAPI support and you can use the web interface. It's a server, so it runs unintrusively in the background. You need it's power, it's already there.

A webinterface as userinterface is only a second-best solution, but in this case it really works out nice: if you surf the web, you are already in your webbrowser. So the tool to work with your desktop server is already up and running. Just open another window or tab and go to your desktop server. No need to run yet another appliction (although you can if you want - XMLRPC is always at your command).

Another nice aspect of the desktop server idea is that the interface is very simple to build and so the application is very simple to extend. No really complicated stuff to do to get your user interface for your own tool up and running. Just use what is already there. The API of the Python Desktop Server are layed out in a way that source is very easy to port between different parts of the architecture: you can write almost the same code in internal tools, in external tools with XMLRPC and in macros and nuggets. This is nice, as you can prototype with macros and nuggets and then move that over to a builtin tool, if the need arises.

Last but not least: the architecture allows very easy remote access via HTTP to your home machine. You just need something like DynDNS or any other dynamic DNS solution and either a flatrate internet connection or some way to trigger your machine to connect at your will. Then just connect to your dynamic name, enter user and password and you can start using your Python Desktop Server installation in the same way as you would do locally!

Sure, hosted solutions like Greymatter or Moveable Type are nice stuff. But a desktop server solution doesn't need to be inferior to them, as the PyDS/PyCS combo show.

Retro-Computing? I show you Retro-Computing!

• 2 Xerox 1186 (running Lyric Lisp)
• 1 Symbolics XL1201
• 1 Symbolics 3645 (deposited at a friend)
• 1 Sun 3/50
• 1 Sun IPC
• 1 Gepard (standalone system!)
• 2 Epson PX-8 CP/M notebooks
• 1 Dauphin DTR-1 Desktop Replacement (Pen-Windows 3.x!)

And several stuff not that interesting and sexy.

PDP11 Emulator, pah!

(okok, I have an installation of MVS 3.8j running on Hercules/360 somewhere on CD)

Note to self: read the Mesa PrincOps, as that might help with the 1186 machines. But where to get a Mesa compiler?