Date: Sat, 31 Jan 1998 18:14:24 -0800 (PST) From: Alex Belits <abelits@phobos.illtel.denver.co.us> To: Mike Smith <mike@smith.net.au> Cc: Terry Lambert <tlambert@primenet.com>, rivers@dignus.com, capriotti0@hotmail.com, capriotti@geocities.com, config@FreeBSD.ORG, joe.shevland@horizonti.com Subject: Re: WebAdmin Message-ID: <Pine.LNX.3.96.980131175440.8348C-100000@phobos.illtel.denver.co.us> In-Reply-To: <199801311108.VAA03258@word.smith.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.3.96.980131175440.8348C-100000>