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

Friedrich Lindenberg friedrich.lindenberg at okfn.org
Tue Jul 5 18:07:04 UTC 2011


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!

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

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

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




More information about the ckan-dev mailing list