I suppose I could file a ticket requesting this, but I'd like to discuss
it first as I feel odd about filing tickets for feature requests that
may not be desirable.
I have a Fossil-hosted project at http://spielproject.info. In this
instance, the project owns the entire domain, and I'd like for the URLs
to reflect that, which they currently do.
However, Spiel has spun off a few subprojects, which I'd like hosted in
their own repositories and with their own websites. I'd like to host
these on spielproject.info at URLs like http://spielproject.info/bazaar,
http://spielproject.info/accessibility-helper, etc.
First, I know that I can accomplish this via web server configuration
and rewrites, so please don't take this in that direction.
When Fossil is pointed to a directory rather than a repository, I'm
wondering if anyone else would find it useful to serve up index.fossil
as the project that is automatically selected if none is given? So URLs
like:
http://spielproject.info/wiki?name=faq
would automatically load the given page in index.fossil, while:
http://spielproject.info/bazaar/wiki?name=faq
would load the page with the same name in the bazaar repository?
This would also simplify configuration some. I currently have two
distinct Fossil configurations, one which points to a directory of all
my various projects hosted at http://dev.thewordnerd.info, and others
pointing to distinct repository names hosted at various TLDs. With
support for index.fossil, I'd only need the directory case pointing at
different directories. TLDs could just replace the index.fossil, and are
then free to spin off subprojects in different repositories simply by
dropping in another fossil.
Note that this would preclude you from naming projects wiki, timeline
and other reserved words for the directory case with an index.fossil
present. Those seem like such specific cases that I don't think they'll
be encountered often enough.
Does this seem like a good idea, or does it make Fossil too complicated?
Again, I know I can do this with web server configuration, but I like
the fact that I can just drop in a fossil and have it served up by the
CGI/server instance, and supporting this case would seem to simplify
that setup even further.
Thanks for reading.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
