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

Mon Feb 22 19:25:28 GMT 2010

John,

All sounds good.

As far as I can tell, the point of recording the tree of patches
ensures patches aren't forgotten or applied twice to a branch.

Example:

Imagine three nodes in our distributed VCS: A, B and C. Let's say that
A has a change to a package that is synced to B. Then B and C each
make changes to the same package. Then C syncs to B and then to A. If
C doesn't find out that B already has the patch which originated from
A, then he will try and merge it to B's version (which B already did).
If you distribute the parents of all the patches then C will avoid
this problem.

Of course you don't need this if you're you stick to a centralised VCS
model or star network. Maybe this is a good simplification for what we
need.

Good proposal for license service. I wonder if it would be better
providing data this as RDF?

David

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