Date: Mon, 2 Feb 1998 02:43:41 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: mike@smith.net.au (Mike Smith) Cc: abelits@phobos.illtel.denver.co.us, mike@smith.net.au, tlambert@primenet.com, rivers@dignus.com, capriotti0@hotmail.com, capriotti@geocities.com, config@FreeBSD.ORG, joe.shevland@horizonti.com Subject: Re: WebAdmin Message-ID: <199802020243.TAA04766@usr01.primenet.com> In-Reply-To: <199802020130.MAA00938@word.smith.net.au> from "Mike Smith" at Feb 2, 98 12:00:37 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> You fail to understand. The entire point that you have missed is that > the 'transaction' that Terry is talking about is a transition whereby a > set of separate parameters assume new values in an atomic fashion. This is exactly what I mean. > HTTP has nothing at all to do with this. HTTP is the language used by > the server to draw the user interface on the client. The server has to > talk to the parameter store, and it is *that* interaction which must > support transactions. It certainly won't be using HTTP. A transaction is an atomic operation on a set of items that you would normally see in a single dialog. In database theory, you would want all of your data in third normal form, and you would have one dialog per database object. The technology used to present the dialog as a set of changes that can be "OK"'ed all at once or "Cancel"'ed all at once is irrelevent. It can be a text form on the console, it can be an HTTP form submission, it can be a JAVAScript client running on a Windows or Mac or Linux box, etc., etc. It doesn't matter. In practice, you can't atomically update the passwd database at the same time you create the user's home directory, etc.. But you can hold them in abeyance until you've done it, so at least you know what's been done and what hasn't after the request comes in. The method I was describing is called "a container object". It's the way you have to do it in LDAP or SNMP, since they don't support any type of transactioning interface. You *could* make "active objects", and write "start" to the "transact" part of the tree, but that's pretty gross, and won't work with all LDAP back ends. Better to work with everything, since you probably want to write a back end that interfaces to the existing databases as a first step. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802020243.TAA04766>