[ckan-discuss] Linking third-party interfaces

[John Bywater]

Hi Dave,

David Read wrote:
> We've got plenty of partners who are keen to integrate CKAN into a
> third-party interface, perhaps to add blogs, wikis and other community
> features and branding. We're now exploring the best way to allow a
> third-party interface to link to the CKAN's package editing pages. The
> Canadian site http://datadotgc.ca/ has achieved this already and I've
> sketched out an API for other sites to do this:
> http://knowledgeforge.net/ckan/trac/ticket/335
> 
> Here's an example:
> 
> 1. The front-end links to CKAN with the 'return_to' URL parameter:
> http://ca.ckan.net/package/new?return_to=http://datadotgc.ca/dataset/<NAME>
> (but with the parameter URL-encoded)
> 
> 2. The user submits the form to CKAN and it redirects the user to the
> new package on the front-end:
> http://datadotgc.ca/dataset/pollution_data
> 
> Feedback is most welcome as ever,

Not exactly sure what requirements this proposal satisfies, but it looks 
like very straightforward to implement, and optimal for static sites.

However, if the client site will support user registration, or if it 
will have any functionality which depends on a user being logged in, 
then a severe discontinuity arises: either the user must register/login 
twice; or the client's users and permissions must somehow be repeated in 
CKAN.

At the same time, the issue with the users and permissions repeats when 
we consider the look and feel: either it will be sharply discontinuous 
with misleading links; or the site's CSS and page layout must be 
repeated in a CKAN theme.

So, it appears that it would work well for clients who either have 
static sites, or do not care about making users login twice, or do not 
care about the impact on maintainability of repeating the user model and 
permissions....

But then only for those clients who either do not care about continuous 
look and feel, or do not care about the impact on maintainability of 
repeating CSS and page layouts!

To provide for all the other cases, and as I tried to explain on the 
telephone, I do suggest we develop a "CKAN Forms API". It would expose 
the forms that are presented in the Web user interface. The forms would 
be presented for use within client controllers. Since CKAN's forms are 
fairly well factored, this would be very cheap to do. It would make much 
more sense, and would provide much more flexibility for client sites.

It would also be very straightforward to implement: support restricting 
usage to client site; make optional the existing CKAN access control; 
and have a simple controller which returns forms and accepts submissions.

Best wishes,

John.