[ckan-dev] Publishers vs. Publisher-centric package management

[p.romain at cg33.fr]

David Raznick <kindly at gmail.com> 
Envoyé par : ckan-dev-bounces at lists.okfn.org
06/07/2011 10:52
Veuillez répondre à
CKAN Development Discussions <ckan-dev at lists.okfn.org>


A
CKAN Development Discussions <ckan-dev at lists.okfn.org>
cc

Objet
Re: [ckan-dev] Publishers vs. Publisher-centric package management






On Wed, Jul 6, 2011 at 8:35 AM, <p.romain at cg33.fr> wrote:

Hi,

I dive in this conversation even if I am not sure to understand all the 
pro and cons of it.

Having looked into what has been achieved by the DGU team, I thought about 
reproducing their architecture for publishing open data material : CKAN 
for storing and organizing data and Drupal for all the animation features.
The first difficulties I had was to understand the authorization process 
linking some cck filed in drupal and groups and authorizationgroups in 
CKAN
I also had difficulties implementing the DGU ckan_package drupal module as 
well as making the ckan app to work. Therefore I end up in the worst 
situation : publishing my content only relying on Drupal features.

If that's acceptable for a first step I am still looking into a more 
stable solution.
 
Currently this is the best solution and is not too far away from how DGU 
works.

>Ok. I thought the interaction was more important. For example, to make 
the nightly dump of the ckan packages available in json, it relies on a 
manual process ?

The publisher issue you arose is a central one to me. I need to be able to 
provide user acces to ckan as well as drupal. I noticed the XML-RPC code 
provided in the ckan-dgu extension but I was not sure how to work with it. 

Is it the authorization model in CKAN that governs the way users role are 
defined in the Drupal architecture or the other way round ?
 
Currently the Drupal architecture is the one that decides the 
authorization.  The xml-rpc just gives ckan the information it needs.

>ok. How did you implement a system that links a drupal "user" to a 
service and therefore a list of packages ? 


All the recent improvement made on the CKAN tool (congratulations by the 
way) also makes my thing about what should be implemented on the CMS side 
and what should be left to CKAN.
The DGU team told me tha they were reconsidering their implementation of 
the interaction between the two but I have no visibility on the direction 
they choose.

Before going further I would need the following elements:

- a clear documentation on how to set up a production environnement of 
CKAN on a linux server (and not only ubuntu distro). I would be happy to 
contribute to the writing of it.
 
The closest thing we have is this 
http://packages.python.org/ckan/deployment.html.  There are many 
documentation initiatives around at the moment and it would be better 
asking others in the team about this one.

>I had difficulties to use this documentation in a red hat environnement 
since some librairies where not available as rpm and had to be manually 
compiled

- a explanation of the way the ckan team sees the interaction of this tool 
with other tools like CMS : is it planned to port all the CMS-like 
features into CKAN or is it reasonable to use CMS like wordpress or drupal 
to intercat with it ?
 
The intention is to have a fully supported drupal integration (and 
potentially wordpress).   This includes opening up all the work by DGU to 
be publicly available and to have a drupal module that is available to 
easily customize your own drupal instance.  We may even make drupal the 
official ckan fronted.

>Are you thinking of using a profile installation of drupal ? I looked 
into the openpublic profile which looks like what could be achieved in 
order to provide an easy way to instantiate a drupal installation 
"ckan-aware"

Concerning publishers, we have not decided the best way yet.  However, 
ckan will become much more drupal 'aware' and will both have access to 
each others database, so this will simplify things greatly.  The simplest 
option would be for ckan to use drupals publishers as an authorization 
source.  This is why keeping publishers in drupal is the best solution at 
the moment.

>ok. But what is the status of those publishers in Drupal: special users 
profile ? a specific cck content type ?

Once this project is set up it would be great to have your feedback into 
the best way this integtration can be done.  We intend to set up a group 
of the people that would like to get involved in this, can I put you on 
the list of people interested? 

> Definitely yes :)

> Pascal
David
_______________________________________________
ckan-dev mailing list
ckan-dev at lists.okfn.org
http://lists.okfn.org/mailman/listinfo/ckan-dev



__________________________________________________________________

Ce message et toutes les pièces jointes sont confidentiels et établis à l'intention exclusive de ses destinataires. Ce message ne constitue pas un document officiel. Seuls les documents revêtus de la signature du Président du Conseil Général ou d'un de ses délégataires sont de nature à engager le Département. 
Toute utilisation ou diffusion non autorisée est interdite. Tout message électronique est susceptible d'altération et le Département de la Gironde décline toute responsabilité au titre de ce message s'il a été altéré, déformé, falsifié.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20110706/9fe70e6b/attachment-0001.html>