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

[Friedrich Lindenberg]

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:

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

2) Are publishers going to be groups?

3) Are there going to be other types of groups as well? If so, how do
we avoid ambiguity in user-land?

4) What speaks against the Agent (User, Group) model where they are
active authorization objects next to normal users rather than just
groupings?

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

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