Same time I complained about not up to date xcache package, I wrote to current maintainer whether I can adopt it. As he promptly agreed to this, we now have up to date package in Debian archives.
The only thing I messed down is that I did upload in hurry and didn't check which all bugs I can close by it. Today it turned out that all opened bugs could be closed, so I made another upload just to close those bugs ;-).
As I wrote in previous post, memcached didn't help as expected with wiki performace, so it was time to look for something else.
Since I'm using lighttpd, I still considered using of XCache, but the Debian package is not really up to date (now it even does not install with current php), so it was too much effort.
But today I decided it's time to try it. I built package from current version (you can get it on debian.cihar.com), installed and it seems to increase performance a lot. Most visible it is on wiki pages, which now take about quarter of time to process. I only hope it won't have any stability impacts, but it survived fine stress tests I did so far.
I've been using memcached for some time on phpMyAdmin wiki and it seemed to help. But recently the performance went down. I didn't have time to investigate it till today and it turns out to be caused by memcached. When I switch it off, page load time goes from 16 seconds to 0.25 seconds.
I tried to search for some similar problems on the net, but I didn't succeed. So for now wiki runs without memcached and I will look at other possibilities of caching later.
Update: If you're interested about versions, it is MediaWiki: 1.7.1, PHP: 5.2.3-1 (cgi-fcgi), MySQL: 5.0.41-Debian_2-log and I have enabled persistent connections to MySQL.
Thing I longer wanted to happen is now becoming reality - Gammu is getting new public API. Man reasons for the change are:
ABI stability. - Till now almost every change in internals of any driver lead to ABI change. If we would correctly increase so name on each ABI change, we would be somewhere near 200, what is not something we could be proud of.
Centralisation of variables cleanup. - Currently all phone drivers have to do some common things in each function. New API allows to centralise those operations in one place.
Exposing of internals. - Old API exposed too much of Gammu internals, what could be misused by programmers and could lead to unexpected behaviour when some internals are changed.
The work is not yet still complete, but the API is getting final shapes right now, so you still have chance to change something. While doing such big change, I decided also to complete documentation of all public functions. This is also currently work in progress, but arising API documentation is already available.
If you are developer using Gammu library, you will have to change some things in your code. To document these changes, new Porting guide has been created. I suggest you not to start with this right now as the API is really not complete and might change a lot during next days.
For long time I use few Python scripts to manage mails on IMAP account. On Tuesday I decided to put them under version control and improve them a bit, because I didn't want to have login information hardcoded in every script.
I made several improvements, added support for distutils and then I
decided that I could also release this to public. I've named them
IMAP utils, I made announcement to freshmeat.net and
Python Cheese Shop (thanks to ./setup.py register)
and now I wonder that these simple scripts have over hundred downloads
and eight subscribers. Maybe it is not that useless as I thought :-).
You might have noticed that current Wammu is not available for Windows. The reason is simple - I was not able to produce working binary in reasonable time. Python-gammu itself seems to work, but when I run Wammu, it crashes quite soon. I tried to debug it for few evenings, but I was not successful.
Therefore I again ask for somebody who would be willing to maintain Windows build. Somebody with Windows experiences will be probably able to resolve problems much faster and will help creating application that will behave good on Windows. I am not able to achieve this as I do not know Windows much and do not use it at all.
I just released version 0.20 of Wammu. This is mostly bugfix release, which fixes various bugs reported by users.
While working on Gammu, I still wonder why people who want to connect their phone to computer buy phones from vendors who use own proprietary protocol or do not share any documentation. Then they come to Gammu mailing list and/or bug tracker and want Gammu to support their phone. Sometimes the fix is easy, but usually it is quite lot of work to debug unknown protocol.
I know this situation quite good from past. I had Alcatel phone, which was using proprietary protocol for access to in phone contacts and events. Fortunately Alcatel released synchronisation software for these phones (it of course runs only on Windows) which had enabled debugging and it was quite easy to understand protocol thanks to logs it could produce. But as newer phones with some extensions appeared, maintaining this became harder and harder.
When I looked for new phone, I decided to buy Sony-Ericcsson K750i phone. Writing support for most of functionality (well in fact all I need) was just matter of few days. The reason why it was so fast was that this phones is using open standards (e.g. OBEX, IrMC) and vendor specific AT commands are documented in freely available documents.
It's your choice how good will your phone interoperate with computer. If you buy well documented piece of hardware, chance to have it fully supported is much higher.
python-gammu 0.20 has been just released. New features:
I just released new version of Gammu, you can download it from download server. Changes to latest testing version are relatively small:
Stay tuned, release evening will continue ;-).