gnokii status

[Pawel Kot]

Hi,

There has been a while since the last gnokii release. There have been
many changes in CVS since then but you might notice that gnokii
development got stale a little. I have been stopping the next release
because I wanted to finish extended phonebook stuff. It turns out that
doing that well involves many libgnokii internal changes (see below).
Therefore I want to release 0.6.15 more less as it is. If there are
some serious bugs or regressions please let me know (or better send
the patch). This is also the time to submit updated translations. See
http://wiki.gnokii.org/index.php/PreBuiltPackages to get built binary
packages with recent CVS.

What gnokii lacks currently is the ability to distinguish the phone
features. We do have gn_phone_model of course but it is not enough.
These are just "thick" features, like whether the phone supports
phonebook at all. But there is no way to say whether the phone
supports certain field in the phonebook. My idea to change this is as
follows.

First of all keep phone database in the external file, so we could add
new phone model without recompiling gnokii. The database should be
plain text (xml counts) to be easily modifiable. Each phone driver
would just be identified by its name. Every phone in the database
would have a driver assinged (one or more). Then, have each phone
model assigned model group (like series40, series60, series60v3 or
similiar).

On the other hand define groups of the features, like: BASIC_PBK (like
with old phones from nk6100 or nk7110), PBK (older phones from nk6510,
fields like PushToTalk related), EXT_PBK (newer phones from nk6510,
fields like addresses, last and first name). Groups of features would
be splitted across group types (PHONEBOOK, CALENDAR, FILE, SMS, ...).
Feature sets would be just for the programming and maintaining
convenience (ie. user should get communicated with certain features).

Then we would define a relation between a phone group and a feature
set by type (ie. phone group A supports feature set C of the feature
type B). The API for this structure would have two methods:
- does phone A support feature D of feature type B?
- what features does support phone A (optionally filterd by feature type B)

Any comments on this? I'm willing to start coding this while waiting
for any problems with current CVS version.

I would like also to make phone and link drivers pluggable (with
libdl). I am willing to port libgnokii to Pocket PC where memory
footprint counts, therefore I'd like to shrink it as much as possible.

And few more words about gnokii future. I feel guilty about the
current gnokii state (ie. almost no development, not enough popularity
-- although libgnokii is used as backend in many apps, no phone
manager with decent gui, ...). If you feel, that you could be a better
maintainer (mostly have more time to devote for gnokii -- helping
users, answering the brown bag questions, maintaining website and
wiki, preparing releases, keeping docs up to date, doing things that
should have been done loong time ago), let me know. I'm willing to
share maintainer position. I will not loose interest in gnokii, but
will spend time on the features I need. And helping new maintainer. :)

take care,
pkot
--
Pawel Kot