On Wed, Oct 1, 2008 at 9:36 AM, Christopher Smith <[EMAIL PROTECTED]> wrote: > On Wed, 2008-10-01 at 09:14 -0700, Bob La Quey wrote: >> > So, SMTP qualifies as loosely coupled because you can replace either side >> > of >> > the system (MUA or MTA) and it still works. Similarly, web servers and >> > clients. >> >> Correct the WWW is loosely coupled, because HTTP is stateless. > > So let's follow this to its logical conclusion: > > - Since it wouldn't add state, if I added a requirement to HTTP that all > requests must be sent in HDF5 format and all responses must be sent as > Word documents (but the server can send back documents from any version > of Word ever made), that wouldn't make it more tightly coupled?
The requirement is external to HTTP, which other than providing the correct response to the request does not care from shot to shot what is being done in the backend. Now somewhere in the back end complex code will be running that converts the HDF5 request into a Word document. But that is not part of HTTP as we know it. > - No matter how many different response codes, commands, encodings, > schemas, mandatory behaviors, etc., we add to HTTP, so long as we don't > add more state, it'd be loosely coupled? Yep, if by it=HTTP. OTOH if it = "the system you build on top of HTTP" may have state and be much more tightly coupled. RE Andy's example of AJAX. > - The WWW is loosely coupled, so it is trivial to write a client that > actually works with Yahoo mail. Yahoo mail is full of Javascript. I suppose I should qualify and say by WWW I meant "old school" pure HTTP. > - The number of states is all that matters, not the complexity of the > state transitions. So, for example, a protocol with 40 states, but only > one state transition possible between each state, would be more tightly > coupled than anything that has been talked about in this thread? He, he .... good counter example. I accept your point. > I'm sorry, but having lots of states does make your validation process > more extensive, but it is not necessarily mean you have tighter > coupling. OK. In the cases you suggest where the transitions are essentially simple then I would say you are correct. BobLQ > --Chris > > -- > [email protected] > http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg > -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
