Write an API standard for dexter-server

[Martin Owens]

Unfortunately because there is no standard on contact storage and indexing (see the empty great hole on freedesktop.org) Dexter has taken to using sqlite via the storm api in order to store and index it's data. The problem is that the schema isn't a standard, the format isn't a standard and the location isn't standard place for contacts.

Basically leading to a dataset which is exclusive and proprietary.

Although not as bad as some (eds etc), at least the code documents the format so the format isn't a black hole, but it's still depressing to see exclusive databases for what is a systematic problem.

The options to improve this would be to use akonadi with another backend, develop a standard in freedesktop.org and separate out the backend code into it's own module. Or deny user contact data needs to be standardised.

[Allen Lowe (lallenlowe)]

Changing the state of freedesktop standards is FAR outside of the scope of Dexter. Dexter's backend is NOT proprietary, it is completely free software, (I know that's not what you meant, but that is what the word proprietary means, and it is an important distinction for me). Dexter has a fantastic dbus api for integration with other apps/services. Also, Dexter will be integrating with libfolks to become even more standardized. However, the use of a new backend that gives Dexter everything I need it to have is hardly a bug, but a feature.

[Martin Owens (doctormo)]

Ah yes, the famous "what I need as a developer is to make the user's system more complex by adding custom data stores"

As an app developer who is creating core user data, why don't you spare a _small_ amount of time looking into standardisation instead of being stubborn and expecting each app to have it's own little barricaded data store? It's not a very systematic approach and your only guarantee that your application will need to be replaced and your user's data converted.

This is exactly why ios and android are going to hand fdo a good kicking. On those platforms you don't so much have "application's address book" as "the system address book" which all apps then use and it makes development a million times easier.

Perhaps it's just a matter of positioning your thoughts around the concept and not so much the technical code you've written. If you put the data in a standard place (say ~/.config/addressbook) and declared that you were the master of the address book standard, at least we'd be looking at it in the right way. You've already got a kick ass dbus interface, so you'd be well in for pushing the standard onto freedesktop.org and posting the dbus interface as the api.

[Allen Lowe (lallenlowe)]

Martin,
Indeed, I have no problem with that. In fact, that's a pretty good idea. If you want to head up that project, I would be happy to bring you into the team. What say you?

Allen Lowe

[Martin Owens (doctormo)]

I says Aye, looking at the code there are a couple of places where the code needs more flexibility added to cope with possible later discussions on schema and then possible changes.

Would you be willing to merge in a code cleanup if I did one?

[Allen Lowe (lallenlowe)]

Martin,
I would be willing, though I have had issues with large code cleanups from other devs in the past, so if you could submit one small patch at a time instead, that would be better. Or maybe just explain all the cleaning up you intend to do.

[Martin Owens (doctormo)]

See lp:~doctormo/dexter-rolodex/data-agnostic-cleanup for test cleanup commit. Anything that delays the nailing down of the schema until you get to the storm backend, is good. What it's trying to avoid is having to change the code in several places if something needed adding.

[Allen Lowe (lallenlowe)]

Martin, I looked at those changes, they look pretty good. Have you tested them pretty well?

[Allen Lowe (lallenlowe)]

unfortunately you can't really use *args successfully with a dbus service method, it conflicts with the signature.