Kallithea URLs

Mads Kiilerich mads at kiilerich.com
Tue Oct 21 13:40:36 EDT 2014


We currently have /images, /css and /js mapped as static files of the 
corresponding kallithea/public/* . That list do currently not include 
the recently added /codemirror . These paths collide with the repo name 
space and I would prefer to not add codemirror there ... and all the 
existing directories are equally wrong.

Also, most admin stuff live under /_admin so you can for instance not 
have a repo called _admin.

It is also not clear for the casual observer whether /code/search means 
a the search page for a repo called 'code' or the summary page of a repo 
called 'code/search'. And when branch names are encoded in paths, it 
gets weird when using branch names containing '/'.

I would like to clean that up and have more clean and semantic URLs. One 
challenge for that is that Kallithea URLs rarely use small integers that 
would fit nice in a semantic URL scheme. We need repository paths and 
branch names with "weird" characters such as '/'.

I would thus like to use something other than '/' to separate parameters 
in the path. I would suggest using '/./' as separator.

The URL namespace could be something like:

/./admin/* (global admin stuff)
/./user/$useridoremail/* (personal stuff)
/./static/* (kallithea/static/* (css, js, images, codemirror), moved 
from kallithea/public/*)
/./json-rpc (old api)
/$repo/./cs/./$rev (changeset)
/$repo/./pr/$number (pull request)
/$repo/./files/./$rev/./$file (file)
/$repo/./log/./$rev (changelog with $rev ancestors)
/$repo/./branch/./$branch (changelog with changesets on branch)
/$repo/./revset/./$revset (changelog with result of revset query)
/$repo/./diff/./$rev/./$rev (compare (from ancestor))
/$repo/./edit (repo settings)
/$folder/./edit (folder settings)
/$folder/./create (folder settings)

'/./' could/should never appear in repo names, it is URL safe, and it is 
quite 'invisible'. I assume nobody would start doing file path 
normalization of URL paths so it should be stable. '//' would be more 
fragile. Alternatively we could use '/_/'. An even better alternative 
could be to use leading '.' to indicate "internal" and thus not support 
hosting of folders/repos with a leading '.' (or '/.') in the name.

routing.py do know which repos we have, so we do not really _need_ the 
separator after the repo name but I think it is nice to have it explicit.

In this proposal I also have the separator before revision 
specifications. That might not be necessary but seems nice and 
consistent to me.

Thoughts and opinions?

I would also like to try to make POST urls be the same as the form URLs.

We can probably keep most of the old URLs for backward compatibility 
until approaching 1.0.

To get back to the topic of the hijacked thread:

 From one point of view, I think it would make sense to build a more 
RESTful API (whatever that means) on top of this URL scheme. But also, 
to avoid the issues of URL encoding and defining URLs for every method, 
it makes sense to continue with the existing JSON-RPC api. That is, 
assuming we can maintain both without too much overhead. And I assume 
the web UI only will use the REST-ish API.

/Mads


More information about the kallithea-general mailing list