[ckan-dev] Feature: new system checkin / status API

[Seb Bacon]

On 9 May 2011 10:12, Friedrich Lindenberg <friedrich.lindenberg at okfn.org> wrote:
> I think this is a technological solution to a largely social problem
> that we should manage instead of coding it. I think the value of
> having the CKAN install telling me that it is around is just much
> smaller than having an actual conversation with its owner (and keeping
> a list of those as we do internally).

On 9 May 2011 10:26, William Waites <ww at styx.org> wrote:
> We can just publicise an opt-in wiki page, put your CKAN instance
> here.

I don't think our social solution works.  See the sysadmin emails this
morning from James.  How do we know its owner?  Only a tiny proportion
of people bother to opt in.  As more organisations want to use CKAN,
fewer and fewer of them have tech backgrounds and/or opting into a
wiki or signing up to a mailing list will be outside their comfort
zone.

On 9 May 2011 10:26, William Waites <ww at styx.org> wrote:
> Note that there is also an action-item from the catalogue interop
> meeting to work out a way of making a big meta-catalogue, and this
> includes but is not limited to known CKAN instances. However this
> gets done will be much more useful than an elaborate CKAN-only
> setup.

I've been convinced a check-in is too elaborate, but how about a
googleable string to help supplement opt-in lists?

On 9 May 2011 10:12, Friedrich Lindenberg <friedrich.lindenberg at okfn.org> wrote:
> Its perfectly legitimate to use
> CKAN in a closed an non-reported way and I know of several such
> deployments. Builidng in a call-home feature costs us time while not
> producing much value for our users, I think.

OK, so the simplest implementation is an API call that reports the
administrator address and CKAN version; plus some kind of googleable
string to enable finding public instances via a web search.  Better?

The proximate value isn't for our users but for us -- knowing who to
contact when there's a security issue or a performance problem is
important in maintaining an ecosystem of software that is seen to be
reliable etc.  However, knowing stats about deployed versions etc will
be quite useful in terms of understanding our community and how they
work, which will in turn help inform directions for the software, so
it certainly benefits them indirectly.

Seb


> On Mon, May 9, 2011 at 11:02 AM, Seb Bacon <seb.bacon at okfn.org> wrote:
>> Hi,
>>
>> For various reasons it's useful and/or important to have a list of
>> installed CKANs and preferably an admin contact for it too.
>>
>> I propose a new config flag "report_existence" which when enabled,
>> pings a central CKAN server to register itself.  It should have some
>> kind of privacy text associated with it to clearly state what is
>> reported if set.  The basic registration process would register the
>> site admin email address, the site name, the site domain name, and the
>> reporting IP address (in case they've set up the site domain name
>> wrongly).
>>
>> An API call would allow us to check the health of the system, update
>> site name, domain, and admin contact at regular intervals.
>>
>> We would also write a simple central registry which lists all systems,
>> and perhaps adds some interesting stats about the systems taken from
>> their APIs.  When the registry can't contact a site, it should email
>> the administrator and ask them to either click on a link to remove the
>> site from the registry, or update the site config file to correct it.
>>
>> We will need to think what to do for existing systems when they are
>> upgraded, w.r.t. privacy implications.  Perhaps fire off an email to
>> the administrator telling them that their site has checked in with the
>> registry, and telling them how to opt out if they like.
>>
>> Finally, the central registry should probably have a way of manually
>> adding extra systems that aren't checking in because they've not been
>> upgraded.
>>
>> How does that sound?  Pending full agreement about CEPs, I will write
>> up a seb-CEP as a test, if we think this is a good idea :)
>>
>> Seb
>>
>> _______________________________________________
>> ckan-dev mailing list
>> ckan-dev at lists.okfn.org
>> http://lists.okfn.org/mailman/listinfo/ckan-dev
>>
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
>