[ckan-discuss] Odd error message from API

[David Read]

So for that use case, a cache/aggregator on CKANs is one way. Another
is federated log-in. Another might be dcat (I don't know much about
it). Another is package syncing. I'm merely suggesting we schedule a
meeting to discuss our needs and compare the solutions before
investing any more in any of them.

I'm still missing the reason that you're worried about detecting edit
conflicts, because I'm surprised (yet delighted) if a package on
ckan.net is updated more than once in 24hrs. There may be other
reasons to consider completely changing our API, but this one doesn't
seem very pressing (yet!).

David

On 1 April 2011 18:26, William Waites <ww at styx.org> wrote:
> Edits happening through the aggregator. Eg a central government functionary edits a record from the central government portal. They don't particularly have or want an account on the municipal government server where the record lives to make the edit there.
>
> The aggregator is not. Intended to be read only so perhaps aggregator is the wrong word
>
>
> David Read <david.read at okfn.org> a écrit :
>
>>Why does your aggregator suffer a high risk of edit conflicts? Just
>>keep it up to date, surely?
>>
>>Dave
>>
>>On 1 April 2011 17:43, William Waites <ww at styx.org> wrote:
>>> The use case is aggregation. I am not worrying about merging. I am thinking about edit conflicts which needs a protocol change i think. The use case of locking down a package just follows logically from this
>>>
>>> Rufus Pollock <rufus.pollock at okfn.org> a écrit :
>>>
>>>>On 1 April 2011 12:23, William Waites <ww at styx.org> wrote:
>>>>> Right.  I think for cases such as yours the data should be pulled from you so you would be responsibkle for whatever handling of revisions on your end.  If someone tried to edit your record on ckan then i think we would arrange for a post back to you which you can handle in whichever way you see fit. Quite possibly preventing edits via that path if that is your wish
>>>>
>>>>CKAN easily supports ability to lock down those packages so only 'you'
>>>>can update them. I really don't think we want to get into thinking
>>>>about revisioning and merging diverging updates here for this simple
>>>>use case :)
>>>>
>>>>Rufus
>>> _______________________________________________
>>> ckan-discuss mailing list
>>> ckan-discuss at lists.okfn.org
>>> http://lists.okfn.org/mailman/listinfo/ckan-discuss
>>>
>