Archive of UserLand's first discussion group, started October 5, 1998.

Re: Response to Flutterby

Author:Dan Lyke
Posted:10/25/1999; 2:07:19 PM
Topic:Response to Flutterby
Msg #:12343 (In response to 12280)
Prev/Next:12342 / 12344

Hi, Dave, thanks for the response. Sorry for the delay, but Scripting News isn't on my daily rotation. And I do need to at least put anchors in my archives, so people can tie to specific entries. Something you said in this message also triggered my understanding of why database backing the whole shebang rather than rendering to static pages would be the right thing, so as soon as I get the new server assembled from the pieces sitting in my living room individual access will be part of my content management system rewrite.

Anyway, my (admittedly acerbic) remark was in essence a response to this: "The system, as we currently have it implemented, seriously bogs down if one or more of the affiliates is not reliable."

The collection of various e-mail protocols, of which SMTP is the most real-time one, is designed to be a delivery mechanism over unreliable links. We've got a huge base of ready built tools for queuing and store and forward mechanisms and such. Not taking advantage of that infrastructure is reinventing the wheel.

And if you read the original intent for NNTP it's totally about syndication of news content. Wouldn't the energy spent building the features of the already debugged and battle-tested NNTP in XML-RPC be better used in expanding the protocol, ala Elf's call to Balkanize Usenet (now, alas, presumably dead).

This seems to me to be a symptom of XML-RPC in general: it's a reimplementation of systems for which perfectly serviceable protocols already exist. I've got agents happily using POST and GET to query databases which have economic incentives to avoid implementing XML-RPC. Obviously some standardization of return data would be preferable, but in my reading XML-RPC doesn't add nearly enough to warrant having to create new clients and server systems to deal with it.

I haven't done all of the research necessary, and I'm not one to defend FTP, but with your web hosting protocol, the advantage seems to be that the requested file name may differ from the actual file name that the server creates. Why not just use result code 257 and leave us the advantage of the huge installed base of FTP capable tools (and ability within the protocol to restart transfers, and all those other advantages)?

(Or am I missing something totally obvious and making an ass of myself?)

I've spent the past several years dealing with both Windows and Un*x, and as such I've done my time on protocols that were implemented because at first blush they seemed to do some specific thing better than the extant standards, and later it becomes obvious that the "obvious" replacement ignored many of the factors that led to the complexity of the first solution. My reluctance to implement XML-RPC instead of these other protocols stems from some of the similarities I see with just about every Microsoft standard that's come down the pike.

I do freely concede that these are the snipings of an armchair quarterback. I'm a low level systems programmer doing my coding for web applications as a hobby, mostly for personal use, and it's easy to take potshots at others from behind that cover. From a tool vendor's standpoint there are all sorts of valid economic reasons to replace the existing protocols, and the criteria for "best" differs wildly from perspective to perspective.

Don't take my attitude personally, I've just found it's the easiest way to cut through the social niceties and ego issues and get to the new ideas. That's where life gets fun.

There are responses to this message:

This page was archived on 6/13/2001; 4:53:11 PM.

© Copyright 1998-2001 UserLand Software, Inc.