Michal Čihař - Blog Archives for Gammu

Yesterday, I finally managed to code something what could be taken as improvement for Sony-Ericsson phone owners. My Gammu branch can now read complete phonebook entries. The implementation is now far from being effective, but works good.

What needs to be improved is way for getting LUIDs, as reading complete phonebook just to get list of all LUIDs is big overhead and causes big slowdown when reading first entry. Parsing IrMC changelog might be a solution, but it would need removing of deleted entries, what is harder to implement. I will try to investigate this possibility later, as this is not required to be handled right now.

While looking at best way how to implement Sony-Ericsson support in Gammu, I found that I desperately need OBEX specification for that. After looking at IrDA website, where it has been designed. I was shocked by prices they request, so I start to look for other source.

Thanks to Jane, I found it! Well they should protect their content if they really want to charge some money...

Marcin, you want to know some problems I see in Gammu+. Okay, I finally found some time to look at it:

1. There is no design document, where can developer find how the code is organised and what is supposed to be API.
2. There is no definition of external API. Everything is mixed together in simmilar way as in Gammu.
3. I don't see reasong for passing pointers (and especially double pointers (eg. DebugInfo) instead of C++ references.
4. Why not using widestring constants instead of converting all using some function?
5. Why there are reimplemented lists in backup? All those GSM_Backup_*Entry IMHO can be replaced by list<GSM_*Entry>.
6. There is too much malloc used (you should need it very rarely in C++).
7. Too much reimplementation of standard C library (eg. wcscasecmp vs. UnicodeCaseCmp).

Okay, I'm tired of reading that code. There is no documentation, the code follows no design, etc. I know Gammu code, so I can a bit understand Gammu+ code, but I expected some more open project, with at least some documentation. If you want to attract developers, you need to document your code.

Gammu+ looks to me like rewrite of C code into C++ while fixing some of design flaws of the old one, but introducing new ones. I know that nobody is perfect, but when starting new project, you should have spent some time on designing it's internals, writing them down and maybe receive some comments from others.

I know nobody is perfect, I also made several projects with wrong design before (well, Wammu is one of the examples).

PS: I don't say that Gammu+ has no future. I only say that it is ulikely to attract more developers as lacks documentation in same way Gammu does. I tried to introduce some documentation it Gammu, but I alone can not document new code…

After playing with it a bit I found out: current Gammu support for this phone is not working at all. After some looking at sources I decided to do implementation same way as in Alcatel - overlay driver which will use AT functions if they can be used. If you're interested in testing, my code will grow in my arch repository (more information on http://cihar.com/gammu), I'm going to submit it to upstream once there will be completed some set of functionality.

Today evening I picked up my new phone on post office and as soon as I arrived home, I started to play with it. And well result for Gammu is poor, there is too much to implement. For now I only added identification, but I will work more on it.

Transfer of contacts was done by gammu --backup data.vcs on old phone and then tranfering to new phone using plain IrDA - ircp data.vcs. This is far from being perfect - I lost most of text in extended entries, half of names is also lost and I expect something might be missing. But I have at least something till I will write full support in Gammu :-).

I had talk about Gammu and Wammu this weekend on LinuxAlt. Video should be online on conference website after some time, but my presentation and text is available right now. You can find it in new section talks. I will have to solve navigation later :-).

Marcin, I don't say that Gammu+ is generally bad. Simply there is not enough man power for Gammu and you will only trash your effort by doing another project. Most of improvements in Gammu+ can be also implemented in Gammu and you will not loose support for lots of phones.

I simply do not think we're powerfull enough to make revolution in Gammu sources which you call Gammu+.

I haven't yet deeply checked it's sources, but I'm affraid of it a bit from few parts I already saw.

I finally ordered new phone for me. I decided to buy it together with switching to T-Mobile as they offered quite good price (and I want to switch anyway).

It will be Sony-Ericsson K750i, so you can expect increasing support for Sony-Ericsson phones in Gammu and Wammu. My goal is to have simmilar feature set as FMA has, what I think should be enogh for most of phone users :-).

If you will be first weekend in November near Brno, you might be interested in LinuxAlt, where I will have a talk about Gammu and generally mobile phones under Linux.

The talk will be in Czech language as most of audience is expected to be Czech speaking.

I already wrote about Google's CodeSearch, but just thanks to blog post about exploring dark corners using it, I found two problems in Gammu code. Bug report with patches is already filed.