[ckan-dev] Fwd: Resource validation

Ian Murray ian.murray at okfn.org
Tue Mar 6 12:41:45 UTC 2012


Moving to ckan-dev list.

---------- Forwarded message ----------
From: Ian Murray <ian.murray at okfn.org>
Date: 6 March 2012 12:16
Subject: Resource validation
To: Ckan-coord at lists.okfn.org


Hi all,

DGU require a little bit of resource validation when linking to files.
 I've written up a quick proposal for CKAN-core here:
http://ckan.okfnpad.org/dgu-package-form (lines 316-428).

In brief: when creating a resource that links to a file (not uploading a
file, nor linking to a service at this stage), an ajax request is made to
the server which in-turn makes a HEAD request to the supplied url.  It then
returns a dict of information that can be used client-side to populate some
of the resource fields.  And also, provide some highlighting (and error
message) if the URL appears to be broken.

There's no validation, it's just a tool to help with the dataset and
resource creation.  ie - there's no URL validation server-side when the
dataset is saved.  I think broken existing links are better found offline
with the qa extension.

There are two things I'm uncertain about:

1. Should this be core functionality, or provided through an extension?
 And if through an extension, which one?  It's own, or would it fit
naturally into a different one (qa, archiver, ...?)

2. Should the HEAD request to the remote server be made off of the
request-thread (ie - in an asynchronous celery task) or not?  Normally with
this sort of thing, I would make the remote request on a seperate process
to that which handles the server's http requests.  However, doing that
would mean:

 a) a barebones ckan deployment would require celeryd (which I'm not sure
we'd want to do?)
 b) a slightly more complicated workflow. (not a problem, just being a bit
lazy)

   And I'm willing to break that rule for this because:

  a) It's only a HEAD request.
  b) It's not a high-traffic part of the site

Any feedback appreciated :)

Ian.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20120306/849ec6ca/attachment.html>


More information about the ckan-dev mailing list