[ckan-dev] Dpm and DataDeck rewriting. What about ckanclient?

[Daniel Graziotin]

Hello everyone,

A couple of years ago, I worked on DataDeck <https://github.com/dgraziotin/datadeck> to make it the standard Python GUI for dpm <https://github.com/okfn/dpm>.
Due to issues with dpm development, I then switched to dpm and helped there. 
Dpm was becoming a mess. Many changes were happening to CKAN, further limiting the development while rising dpm complexity.
There were nice ideas floating around dpm; one of them was to turn it to the git of OpenData (sort of). Unfortunately, I could not be of more help and development stopped.

Nowadays, dpm is old and bloated while DataDeck is completely useless. I would like to dedicate some more time to the OpenData movement. 
My free time is still scarce (I am a PhD student) but I am planning to rewrite dpm / fork it to sdpm, or simple data package manager. 
I would like to have it working a la (Debian) APT, plus the creation and upload of packages. Nothing more than that.
When sdpm reaches some maturity, I would like to rewrite my DataDeck to support it.

Luckily, @CKANproject on Twitter has just pointed me to the recent discussion "API docs update" <http://lists.okfn.org/pipermail/ckan-dev/2013-February/003891.html>.
Dpm relies on ckanclient. Now I see that there is uncertainty with ckanclient as well.
I am with those who want ckanclient to exist: other people rely on it, e.g., me :-)

What do you think about the sdpm + DataDeck idea? Think of the couple like apt and Synaptic package manager
Regarding the API version / ckanclient: should I use the actual ckanclient? Should I wait for a better ckanclient instead?
I could spend some effort on ckanclient. However, I am more confident on developing at a higher level. 
Another reason to work on a simple dpm would be to focus only on a part of the APIv2/v3, to keep complexity down and maximize my effort in my limited free time. 

Any feedback / counterproposals?

Best Regards,

--Daniel Graziotin