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

[David Read]

On 4 July 2011 19:26, Friedrich Lindenberg
<friedrich.lindenberg at okfn.org> wrote:
> Hi all,
>
> (replying to myself here, but this is after some good discussions during OKCon)
>
> I'm not quite sure how this was settled during OKCon, so I want to
> pick it up again, because its fairly essential:

I'm currently implementing http://trac.ckan.org/ticket/1198 which I
think is a pretty uncontroversial start to this work.

> 1) Are we going to have a one-many association between packages and
> publishers (one publisher per package)?

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.

> 2) Are publishers going to be groups?
>

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.

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

> 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

David

>
> Thanks,
>
>  Friedrich
>
> On Thu, Jun 23, 2011 at 12:44 PM, Friedrich Lindenberg
> <friedrich.lindenberg at okfn.org> wrote:
>> Hi,
>>
>> On Thu, Jun 23, 2011 at 12:11 PM, Rufus Pollock <rufus.pollock at okfn.org> wrote:
>>> On 23 June 2011 10:54, Friedrich Lindenberg
>>> <friedrich.lindenberg at okfn.org> wrote:
>>>> Hi all,
>>>>
>>>> I'm happy to see were going to make Publishers first-class citizens in
>>>> CKAN. Still, I'd like to advocate going the whole way on this and
>>>> introducing a github like, user-centric package model. I've detailed
>>>> this in a comment:
>>>>
>>>> http://trac.ckan.org/ticket/1199#comment:1
>>>
>>> Correcting: <http://trac.ckan.org/ticket/1198#comment:1> (BTW: this
>>> should definitely be a *separate* ticket).
>>
>> Yes, it should be a separate ticket but I wanted to prevent us from
>> creating a Publisher ("in the mean time") object that would then begin
>> generating its own PK IDs, making it harder to join up with the users
>> table in the proposed Agent table. Why not create these basic domain
>> objects now, instead, and then fix Authz and URL routing later?
>>
>>> One thing this will emphasize / require though is forking ...
>>
>> Yep, I hope this will help the poor package relationships (so useful
>> in theory, so awkward in practice) to a nice use case....
>>
>>>> Just to underline: I don't mean this needs to be done by next week
>>>> (although, why not..) but that it is the general thing we should agree
>>>> on.
>>>
>>> Understood. I've created a pad for putting down stuff we want to work
>>> on / talk about during the sprint:
>>
>> Your turn with the link :-)
>>
>> - Friedrich
>>
>>> Rufus
>>>
>>> _______________________________________________
>>> ckan-dev mailing list
>>> ckan-dev at lists.okfn.org
>>> http://lists.okfn.org/mailman/listinfo/ckan-dev
>>>
>>
>>
>>
>> --
>> Open Knowledge Foundation
>> Promoting Open Knowledge in a Digital Age
>> http://www.okfn.org/ - http://blog.okfn.org/
>>
>> http://twitter.com/pudo
>> http://pudo.org
>>
>
>
>
> --
> Open Knowledge Foundation
> Promoting Open Knowledge in a Digital Age
> http://www.okfn.org/ - http://blog.okfn.org/
>
> http://twitter.com/pudo
> http://pudo.org
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
>