nice new hackage urls
Duncan Coutts
duncan.coutts at worc.ox.ac.uk
Sat Jul 4 13:01:13 EDT 2009
On Sat, 2009-06-13 at 22:50 +0000, Duncan Coutts wrote:
> Yay! :-)
>
> Thu Jun 11 16:40:34 BST 2009 Ross Paterson <ross at soi.city.ac.uk>
> * shorter package URL
> hunk ./Locations.hs 61
> -pkgScriptURL = "/cgi-bin/hackage-scripts/package"
> +pkgScriptURL = "/package"
>
> And I see the old urls work too, presumably using the magic of apache
> url rewriting.
So, I'd like to update cabal-install to use these new URLs in the next
minor release. It's good since it'll also match the URLs for the new
hackage server, so it no longer needs a special case in the code in
cabal-install.
This made me recall that one place we do still have a special case for
the current central hackage server is when we specify the upload and
check POST URLs. Currently hackage uses:
/cgi-bin/hackage-scripts/check-pkg
/cgi-bin/hackage-scripts/protected/upload-pkg
At the moment, cabal-install just hard codes these URLs when it notices
that we're using the main hackage server. When we're using any other
server (assumed to be the new hackage-server impl) then we use
$serverroot/upload. I'm not sure this is ideal.
So I suggest we find a common standard URL, eg:
$serverroot/packages/upload
$serverroot/packages/check
and make the current server use that as an allowable alias for its
existing cgi scripts, and adjust cabal-install and the new hackage
server to do the same.
Why these URL names?
* /package/ is for the individual packages, everything under this
is a package name (with optional number)
* /packages/ is for resources related to the collection itself, as
opposed to individual members of the collection, so things like
the collection index etc.
Sound sane?
(In theory, "well known" URL schemes is not the right RESTful style and
we should have some resource that points to the various sub-services /
resources)
Duncan
More information about the cabal-devel
mailing list