> I apologize in advance if this has been already
> discussed, but why wouldn't you put the "service
> maintenance" options (create, update, delete, list)
> in a separate executable, like svnservice.exe or something?
Well, there are legitimate reasons to go down both design paths. Consider
the strengths and weaknesses of the "merged" binary (installation code
within svnserve) vs the "separate" binary (installation code in some other
binary, say, svnserve_installer.exe -- an ugly name just for the purposes of
clarity here):
Integrated approach: Strengths
* The installer can always find the svnserve.exe binary.
There is never a problem with not being able to locate
the svnserve.exe binary.
* Version mismatches are impossible, since the installer
code is in the same binary.
Integrated approach: Weaknesses
* A tiny amount of code is included in the service binary.
This is incredibly negligible, but someone is bound
to mention it.
* The possibility of user confusion, regarding how services
are installed and run. Someone is bound to try running
"svnserve --service" from a command-line. When they do
that, the process will call StartServiceCtrlDispatcher,
which will attempt to register the process with the
Service Control Manager. This will fail after about 30
seconds, and the user will see a message saying "You're
not supposed to start this process that way." But at
least the failure is deterministic.
Separate approach: Strengths
* Clean separation of functions appeals to geek aesthetics.
SVN service logic goes in svnserve.exe. Installation /
management logic goes in some other binary.
* Having a single installation / management binary that can
do both command-line and GUI management is appealing.
Note that, because of the "GUI / CLI" bit in Win32 EXEs,
it may be necessary to have a management DLL, with tiny
"shim" EXEs that bind to it. This is also appealing.
Separate approach: Weaknesses
* Another binary to build and keep track of.
In summary, I would be happy with either approach. They both work. The
most important issue is then: How do we provide the most rational, reliable
interface to our users? As long as the user experience is reliable, and
well-documented, I'm ok with going with either approach.
-- arlie
-----Original Message-----
From: Mark Phippard [mailto:markp@softlanding.com]
Sent: Tuesday, February 21, 2006 4:04 PM
To: Arlie Davis
Cc: dev@subversion.tigris.org
Subject: Re: Proposal for svnserve as a Windows service - 0.1
"Arlie Davis" <adavis@stonestreetone.com> wrote on 02/21/2006 12:34:10 PM:
> Summary
> -------
>
> svnserve would be modified to add support for running "natively"
> as a Windows service. This allows svnserve to be managed like any
> other Windows service (start / stop from "Services"
> management tool, see status, manage it remotely, etc.), to be reliably
> started when the system boots, and to be reliably stopped when the
> system shuts down.
>
> Support will be provided for installing, enumerating, and uninstalling
> instances of svnserve services. The implementation would support any
> number of svnserve repositories; there will not be any limitation on
> the number of installed services.
I apologize in advance if this has been already discussed, but why wouldn't
you put the "service maintenance" options (create, update, delete, list) in
a separate executable, like svnservice.exe or something?
And just limit the changes to svnserve.exe to those needed to actually run
as a service? That seems like it would be a lot cleaner and greatly reduce
the changes need to svnserve.exe itself. I do not like the idea of all of
those command line options being added to svnserve.exe.
svnservice.exe could also just be a GUI with command line option support if
you were to go in this direction and then there would be less pieces to deal
with.
Thanks
Mark
____________________________________________________________________________
_
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM
Email Security Management Services powered by MessageLabs.
____________________________________________________________________________
_
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Feb 22 02:53:24 2006