[ckan-discuss] initial considerations for distribution of CKAN model changes

[John Bywater]

Hi David,

David Read wrote:
> John,
> 
> All looks very promising - great stuff! Covered loads of stuff. Here
> maybe be a few more issues to consider if you've not already.
> 

Thanks a lot!

> One requirement mentioned last week was for manual moderation of each
> patch. i.e. you may want to accept some patches but reject others, for
> your ckan instance. So not automatic merging in all cases.

Think that's already there, but not prominently. See: "other behaviours 
could include: automatic merging; automatic skipping; intervention each 
time" on that page...

> 
> It might be worth thinking about exactly what you might see when you
> hit 'Recent changes' or 'Package history' in ckan.net. The implication
> from your design is that you see all revisions that you've 'pulled'
> from elsewhere. I guess each revision would say who its parent(s)
> was/were, and which instance of ckan it was changed on.

I don't understand the role of parent(s) at the moment - it seems to be 
a concept of Mercurial that doesn't carry over. They are used in 
Mercurial to seed to subsequent changeset number, as part of the 
conflict detection mechanism, and to piece together the glog?

Although all revisions would pertain to changes made to the local model, 
the *source* of those changes could be recorded (to refer to a patch, or 
local edits, or ckan client, etc.). The patch could then record which 
CKAN instance and revision (for audit trailing?), and this information 
could be presented in the Recent Changes.

> 
> There's the issue about ckan instances talking to each other that are
> at different software versions. So maybe a concept of an API version?

Yes. I think this should mostly become part of the REST API (which would 
simply present the changeset patch model, and possibly the changeset 
publish-subscribe model if we get that far). So perhaps the REST API is 
already versioned? If not, capabilities detection would probably work 
for backwards compatibility.

But if we can get this "right first time" (like Mercurial) I'm sure it 
would help....

> 
> Another use case I'm keen on, is to allow ckan.net to be two ckan
> instances kept in tight sync. Then you can take one down for
> maintenance / data schema migration, and the other takes the requests
> and edits. Then when it's ready you can just sync to its buddy to get
> the outstanding changes.
> 
> And I'm not aware we've come to any conclusion on how to distribute
> the license names/ids since these aren't versioned.

They could be factored out from CKAN (possibly according to the 
suggestions I made regarding servicization of licenses data package last 
week):
http://www.knowledgeforge.net/okfn/tasks/ticket/255

Best wishes,

John.


> 
> David
> 
> On 22 February 2010 17:57, John Bywater
> <john.bywater at appropriatesoftware.net> wrote:
>> Hi all,
>>
>> As requested, here are some initial considerations of mine regarding the
>> distribution of CKAN model changes:
>>
>> http://knowledgeforge.net/ckan/trac/wiki/DistributingChanges
>>
>> Summary overview:
>>
>> - brief summary of the "want and needs"
>>
>> - coarse-grained comparative analysis of Mercurial and CKAN (because it was
>> thought that Mercurial solves a similar problem to that which distributing
>> CKAN changes addresses)
>>
>> - concepts of Mercurial that strictly don't apply to CKAN are indicated
>>
>> - concepts of Mercurial the do carry over to CKAN are also indicated
>>
>> - actions needed to distribute changes between instances are indicated
>>
>> - the names of the discarded Mercurial concepts are then reused to direct
>> those actions
>>
>> Feedback always gladly received!
>>
>> Best wishes,
>> John.
>>
>>
>>
>> _______________________________________________
>> ckan-discuss mailing list
>> ckan-discuss at lists.okfn.org
>> http://lists.okfn.org/mailman/listinfo/ckan-discuss
>>