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

[David Read]

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
>