http://localhost/query?status=!closed&cc=~james&order=summary The open source data portal software en-US http://assets.okfn.org/p/ckan/img/ckan_logo_shortname.png http://localhost/query?status=!closed&cc=~james&order=summary Trac 0.12.3 http://localhost/ticket/1165 http://localhost/ticket/1165 Thu, 26 May 2011 12:41:07 GMT nils.toedtmann <p> Currently, each ckan site needs its own ckan wsgi process. That eats a lot of resources where many ckan sites are served from one machine (e.g. eu3). </p> <p> That would dramatically change if a ckan process could behave like multiple ckans (e.g. like Apache's "&lt;<a class="missing wiki">VirtualHost?</a>&gt;", or tracd). Depending on the "Host:" header in the HTTP1.1 request, it would choose which local ckan ini file to obey. </p> <p> I see two ways to constitute the map hostname-to-ini-file map: </p> <ul><li>ckan reads a set of ini files, and each ini file declares which servers names it is responsible for </li><li>In a global ini file, there are directives mapping servernames to ini files. </li></ul><p> In either case there should be a global ckan ini having the default settings for all local ckan sites. Each site ini could be very short then, just having e.g. title, name, database credentials, active plugins etc. </p> Results http://localhost/ticket/1165#changelog