From owner-freebsd-config Sat Jan 31 18:13:04 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA25274 for config-outgoing; Sat, 31 Jan 1998 18:13:04 -0800 (PST) (envelope-from owner-config) Received: from phobos.illtel.denver.co.us (abelits@phobos.illtel.denver.co.us [207.33.75.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA25269 for ; Sat, 31 Jan 1998 18:13:02 -0800 (PST) (envelope-from abelits@phobos.illtel.denver.co.us) Received: from localhost (abelits@localhost) by phobos.illtel.denver.co.us (8.8.8/8.6.9) with SMTP id SAA13339; Sat, 31 Jan 1998 18:14:26 -0800 Date: Sat, 31 Jan 1998 18:14:24 -0800 (PST) From: Alex Belits To: Mike Smith cc: Terry Lambert , rivers@dignus.com, capriotti0@hotmail.com, capriotti@geocities.com, config@FreeBSD.ORG, joe.shevland@horizonti.com Subject: Re: WebAdmin In-Reply-To: <199801311108.VAA03258@word.smith.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 31 Jan 1998, Mike Smith wrote: > I will ask again; would people *PLEASE* take this conversation to > -config, where it belongs. ok > > On Sat, 31 Jan 1998, Terry Lambert wrote: > > > > > I think that the atomicity of the transaction for HTML is an implementation > > > detal; a detail best served by defineing how a transaction is to take place. > > > > > > That the HTML post is a "transaction" is seperate from "what to do when > > > an HTML post is seen and you are an HTML server". > > > > Of course, implementation can treat it as a transaction or not. I only > > mean that HTTP protocol with forms uploaf provides a mechanism that allows > > HTTP server to use transactions regardless of the model used by client for > > its actions as long as the client uses HTTP. > > HTTP has *nothing* to do with the parameter store. HTTP is an > abstraction within the presentation layer ("user interface"). > > If you are using HTTP in the presentation layer, it is the actions > performed by the "server" side of the HTTP interface which need to be > grouped in a transaction. Terry's 'container object' technique is > about the only way to do it; in fact it *is* a transaction technique > with the internals of the process exposed to the consumer. I disagree with that. HTTP is not a user-interface protocol (what, say, X protocol is), user interface is one of possible HTTP applications. HTTP has means that define the boundaries of transaction, and container object in HTTP-based implementation may exist only in the memory of the program that serves requests while client (not necessarily one that uses HTML -- HTTP can be used without HTML, and even without URL-encoded form upload -- one can encapsulate into HTTP whatever one pleases as long as it can have some atomic transmission that can have MIME header added to it) only groups some data into single form (or comma-separated list, or encapsulated into HTTP set of SQL requests, or whatever else) thus having completely unrelated object (say, list of strings, prepared for form upload) that doesn't have to make its identifier known to anyone else -- the result of transaction will be associated with it because it will be the answer to the HTTP request containing it. I agree that HTTP is not the only thing that can be used there, I only think that it's more appropriate as the protocol because it leaves consistency relying on the server and not on the client's behavior. -- Alex