2010/1/31 D. Richard Hipp <[email protected]>

> There was another recent request for the ability to serve multiple
> repositories off of the same TCP port without using a web server.  The
> current syntax to launch a stand-alone server is:
>
>       fossil server REPOSITORYFILE
>
> Suppose we expanded this to allow multiple repositories to be named on
> the command-line.  So if you had a directory full of repositories, you
> could do:
>
>       fossil server *.fossil
>
> Suppose the names of the repositories files are abc.fossil,
> def.fossil, ghi.fossil and so forth.  Then to reach each repository,
> visit:
>
>     http://localhost/abc
>     http://localhost/def
>     http://localhost/ghi
>
> And so forth.  If this functionality were implemented, then the cookie
> names would be fossil_login_2F616263, fossil_login_2F646566, and
> fossil_login_2F676869.  Since the cookie names are different, you
> could log onto all repositories all at once.  If no repository is
> specified in the URL (if  you enter http://localhost/) what should it
> do?  Show an error?  Return a list of repositories?  Choose the first
> one named?
>
> Perhaps the syntax should be:
>
>     fossil server --directory FOLDER_HOLDING_REPOSITORIES
>
> In that case, fossil is able to serve any fossil repository in the
> named directory.  The particular repository chosen by the path in the
> URL.  With this syntax, new repositories can be added to the site
> without having to restart the server - simply move files into the
> appropriate folder.  We still have the problem of what to do with an
> unknown path.
>

I like these ideas a *lot*, Richard.  As in I like all of them.  For just
quickly sharing a specific repository you use the single-file version (the
default as now).  If you want to share specific repositories but not all of
them, the multiple repositories on the command line is perfect.  If you want
to host many repositories and expand/contract them as needed without
restarting the server your directory syntax is perfect.

If you enter just the root there's arguments for two approaches:

   1. The open approach is to list all the accessible repos.
   2. The more security-semi-conscious approach would be to assume someone
   hitting the root isn't authorized to access any repository and thus should
   gets flipped the bird, metaphorically.
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Reply via email to