Greg Stein wrote:
> Karl Fogel wrote:
[ ... ]
> > Are you talking about the CGI script, Josef?
Well, sort of... Please see below...
> That is just side-stepping the issue. Josef's point is that
> we have not provided any useful feedback about his script.
Thank you for clearing this up :)
> And that its existence is very much tied to whether the APIs
> should remain or not. That is: if you decide to lose the
> functionality, then the importance of his CGI is
> increased. And the contrary, of course.
Exactly. That is why I asked several times: "Do you believe this
is the right way to go?"
> Josef: I know that I haven't really responded because using a
> CGI for basic operation is even less interesting to me [... ]
Well, i call it "CGI" because it started its life as a CGI. Actually,
it have evolved much beyond that:
a.) It simplifies repository creation:
1.) creates initial files/directories according to predefined templates.
2.) set up initial properties according to predefined templates.
3.) set up initial commit-access according to predefined templates.
(e.g. no commits to /branches, no commits/deletes to /releases)
4.) set up initial commit-emails according to predefined templates.
5.) set up initial htpasswd.
b.) It provides a "generic" hook-script. That is, it installs itself as
hook-scripts and does all the things that hooks should do:
1.) checking commit-permissions
2.) sending commit-emails
3.) making repos-backups
4.) cleaning db-logs
c.) It provides basic administration (e.g. dd/delete users, change
passwords)
d.) It offers basic repos-maintanance (e.g. tweaking commit-logs)
e.) It provides a CGI front-end to access/configure all of the above.
The CGI is just a front-end to access/configure the tasks mentioned
above. I think it would not be a big deal to add additional front-ends
(I actually have plans about a Tk interface and a command-line
interface)
> To have to set up a web server and a CGI script to get this
> functionality...
Not at all. The hook-functionality is fully functional without a
web server. You can configure it with vi/emacs. And as I already
mentioned: I have plans to add different front-ends so no one
is forced to use the CGI front end. It's just that the CGI is
convenient because you do no more need to log into the server
just to do basic maintanance of the repos.
While it has started its life as a CGI it does not need to remain
a (pure) CGI forever. But before I continue on this work, I would
like to know whether people think that this is the right way to go.
I am not really interested in creating/maintaining a beast which no
one is going to use.
> Second, I don't like the security implications of such a system.
> I don't like seeing that much privilege/power in a CGI script,
I see. What if this script would offer a different UI and there would
be no more reason to install it as a CGI?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 9 12:33:15 2003