Date: Sun, 1 Feb 1998 21:18:49 -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.980201195836.19801A-100000@phobos.illtel.denver.co.us> In-Reply-To: <199802020130.MAA00938@word.smith.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2 Feb 1998, Mike Smith wrote:
> > > 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.
>
> 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.
HTTP request with data is exactly the same thing. Implementations often
completely defeat this feature, however the protocol allows to define
transaction unambiguously, and without any identifier that should be known
and supported by both server and client.
> 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.
HTML is. HTTP isn't. Two different things.
HTML can be sent from server to the client over HTTP, FTP, NNTP (weird,
but possible), SMTP, and, for real perverts, TFTP. HTML form upload can be
sent to the server over HTTP or SMTP. Of course, the most practical way is
to use HTTP, but it has nothing to do with HTTP being anyhow tied to HTML
-- just HTTP is the most practical protocol for the pattern of short
upload-then-download or request-then-download cycles that are typical for
the access to passivel waiting server with relatively large amount of data
to receive (so hundreds of bytes per operation spent on headers are
justified).
HTTP can be used to send to the client HTML, GIF, plain text, RFC 822
message, comma-separated list, tab-separated list or URL-encoded form
list, not ot mention any kind of file format, MIME type exists for. HTTP
can be used to upload from the client to the server exactly the same set
of data formats that can be downloaded -- there is no special restriction
for it in the protocol, however existing _browsers_ (not all HTTP clients
are browsers) are interactive programs, and that places restrictions on
what they send and use.
> 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.
Server, when talking to the local parameter store should use whatever
allows atomic transactions, and transaction may fail for something that
will be outside the local transaction mechanism. Ex: local transactions
mechanism is file locking and running scripts on completion. Server
received the set of parameters, locked the files, changed their content,
unlocked, started reconfiguration scripts, scripts returned an error.
Transaction, defined as files change, succeeded, but overall transaction
that has its meaning for the system configuration, failed. Properly
designed administration system should reverse changes and reconfigure
system again, because in some case otherwise you will get unreachable
system, and the whole idea of remote configuration will be defeated. If
server managed to "fix" system to the state that system had before the
transaction started, it should report transaction failure to the client.
If not, client should receive some error that indicates the transaction
failure and impossibility to restore pre-transaction state, and that
should be a thing to worry about, however at least it's some situation
where in most of cases it's possible to report or detect fatal error
cleanly.
All that can be implemented easily over HTTP, and the "fatal error"
condition in the best case produces the error message to the request, and
in the worst case leaves the system unreachable and produces protocol
error.
However it's possible to do other, more complex things using this
transaction without identifier mechanism. Say, the change of configuration
should be applied to the group of machines because in its case group acts
as the whole -- say, fileserver, authentication server and clients of
both. Administration box will issue requests for changes in the order, it
(or its sysadmin), considers to be appropriate, and if everything
succeeded the whole transaction is succeeded on it. If not, it will be the
responsibility of administration box (acting as a client for others) to
reverse changes on boxes where their part of transaction failed.
It's possible that transaction is done for the group of hundreds of
boxes. One administration box will be impractical, and many administration
boxes are organized in tree-like fashion, using some protocol (say, HTTP).
Then every local administration box has its own transaction that is a part
of main transaction, and it may be necessary to have local recovery
procedure confined to the local administration box. In this case one
should ask local administration box to reverse the already finished
transaction, and unless main administration box wants to deal with all
changes on all local boxes, it will need to tell local administration box,
which transaction to reverse. This is the only case when identifiers that
should be known to both server and client are really necesary -- it's the
identifier of transaction that should be reversed. However that
transaction may contain huge number of objects and in itself it can be a
macro, globally or even locally defined for the network ("change
nameserver to local nameserver for subnet if it exists, otherwise to the
new nameserver"), so main administration box may never know what objects
are actually changed. It also can be nested -- once local transactions can
be opaque and contain macros, it's possible to nest them over multiple
servers, thus making a tree. IMHO this kind of system is more clean and
extensible.
--
Alex
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.3.96.980201195836.19801A-100000>