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