|
Greg asks why the Python Desktop Server uses a desktop server like Radio Userland does. And why not a hosted server solution, like Moveable Type (and why - if we can build all that functionality into a desktop server - we don't build a MT plugin or something like that). I try to anser that here. 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. |
