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

p.romain at cg33.fr p.romain at cg33.fr
Wed Jul 6 07:35:45 UTC 2011


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.

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 ?

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.
- 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 ?

Best,
Pascal Romain




David Read <david.read at okfn.org> 
Envoyé par : ckan-dev-bounces at lists.okfn.org
05/07/2011 22:58
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 5 July 2011 19:07, Friedrich Lindenberg
<friedrich.lindenberg at okfn.org> wrote:
> Hi David,
>
> thanks for your reply!
>
> On Tue, Jul 5, 2011 at 12:38 PM, David Read <david.read at okfn.org> wrote:
>> We need more than one publisher per package for DGU. I think this
>> needs to be flexible, through a pluggable authz system that David and
>> James are discussing. I'd like to see a proposal / CREP for this.
>
> Is there really, really no way to model this other than multiple
> publishers? I really think we need to simplify things and package
> ownership is one amazing way to do this. Many to many is not
> ownership, its ACLs again. Many to many does not give us nice URLs or
> nice interaction patterns (forking, merging, ...). Many to many does
> not reduce complexity, it adds to it. Please, please reconsider!

I'm beginning to understand where you're coming from. You want the
Github feature where a person or group 'owns' a Package. I'd have
thought it's be useful for a User to fork a Resource and play with it,
but I'm not seeing the advantage of multiple copies of a Package.
Haven't we scrapped this Distributed VCS idea for Packages (see JB's
code from last year) in favour of a single trunk of changes in, edited
if necessary through Moderated Edits on the source CKAN and harvested
as Read-Only copies into other CKANs if sharing is desired?

Whatever your reasoning, I think we could make the DGU model fit with
your ideas. We could have a package owned by only one publisher, yet
we'd want to associate other publishers. The values for all these
publishers would still need to be controller by the authz, as well as
well as the authorization to edit them would be based on the values of
all these fields - but this would only be in a plugged-in authz
system, rather than the default CKAN one. What do you think?

>> Yes, that's now the plan - I can't see why not reuse Groups. David has
>> added a Member class which makes Users join many-many with Group - see
>> the branch feature-1198-publisher-hierarcy if you are interested.
>
> I think they are different: one is for creating collections of things,
> which arguably overlaps with packages themselves; the other is for
> managing things and controlling them. Of course its nice to have a
> general I-can-attach-both-packages-and-users-to-it entity, but I would
> argue that it is not actually a design: what usage does it *imply*
> rather than just enable?

The particular packages that a user is allowed to edit is commonly the
same packages that are 'owned' by the publisher he/she works for. So
being able to link users to publishers and making this data available
to the module which grants or denies access is I think a reasonable
design. This might not always be the authz logic of course. The authz
module you plug in for a different project may prefer to use the
current Role-Base ACL, or new another set of user groupings like the
one you suggest. I don't see the pluggable authz idea as a blocker for
your github-style ownership idea, or is it?

>>> 3) Are there going to be other types of groups as well? If so, how do
>>> we avoid ambiguity in user-land?
>>
>> I'm not understanding you - do explain what confusion could arise.
>
> Well, I think we're going to end up with a system in which people will
> recognize that groups and publishers are related - in the worst case
> it will be some dropdownish thing - and then get confused over the
> distinction and end up using neither.

I'm still lost... Are you talking about the admin who installs a CKAN
and sets up the publishers and users? Or the person creating a package
choosing a group for it?

I guess the key thing is that the model is understandable. I'll agree
that Groups are a little tricky to understand, and the new 'Member'
class might be as difficult as AuthorizationGroups are now. I don't
think Agent is ideal though. We can work on the terminology, but yes
do suggest improvements to the modelling too.

David

>>> 4) What speaks against the Agent (User, Group) model where they are
>>> active authorization objects next to normal users rather than just
>>> groupings?
>>
>> As I said before, this seems a reasonable improvement, but since we're
>> moving the authz into plugins then this needs to be considered.
>>
>>> From my PoV the Agent model would be very simple to implement, very
>>> clear also in the conceptual model and it would allow for the new URL
>>> scheme which I'm really a big fan of.
>>
>> +1 to the URL scheme
>
> Again: doesn't make *any* sense for many to many where you then end up
> with several URLs for the same package. Of course you can hide this
> somehow but thats just terrible design.
>
> - Friedrich
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
>

_______________________________________________
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/f229746c/attachment-0001.html>


More information about the ckan-dev mailing list