Date: Mon, 2 Feb 1998 07:04:21 -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.980202055505.22138A-100000@phobos.illtel.denver.co.us> In-Reply-To: <199802020903.TAA02101@word.smith.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2 Feb 1998, Mike Smith wrote: > > without increasing the number of protocols involved. > > You have completely and utterly failed to comprehend what is going on > here, in the face of several clear explanations and plenty of > references. Let me try again. > > HTTP is not an *available*option* for talking to a distributed > parameter store, unless you happen to have written one and stashed it > up your sleeve. There are ones that do it -- I wrote one implementation of HTTP backend that handles requests in the manner, required for that, but it's not the only thing of this kind. > Thus, it doesn't matter the slightest whether HTTP supports > transactions; the only available distributed backend that we are likely > to be able to use (LDAP) DOES NOT (at this point in time). > > Are you following me so far? No, I'm incredibly dumb. > OK, about now, you are going to try to > ask about HTTP <-> LDAP gateways. I hope you stop first and consider > how the gateway proposes to guarantee the atomicity of the series of > operations that it has to perform in order to complete the HTTP > transaction. It can't, short of using a container object. Now, what > were we saying about container objects before? If a protocol that does not support transactions in itself is involved, you have to use container object with identifier, known to both server and client and tie transaction to the operation on that object. What I fail to see is the advantage of using LDAP in this case -- just being a directory service hardly can be a sufficient qualification for suitability as remote configuration protocol. > Please. Try to stick vaguely close to reality. If you want to > *implement* your reality, then by all means, go right ahead. I don't have the implementation of configuration editor/manager for FreeBSD and servers hierarchy system that I have described earlier. However requests processing model that I have implemented in my HTTP server can easily be used as the base for such system. I will like to develop it further (generalized parameters store to HTTP interface, configuration update operation that can fail for succeeded store update and require reversing transaction, and servers hierarchy support -- it's all not a rocket science, unless implementation means are crippled by, say, CGI interface). The problem is that if I'm the only person who see it as a possibility, there will be little reason using that for FreeBSD configuration -- it's a large project, and even if I'll write some basic configuration in that, flexibility of it (if it will be implemented right) will be wasted if no one else will want to write parts and extensions for it. -- Alex
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.3.96.980202055505.22138A-100000>