Alan Milligan <alan@xxxxxxxxxxxxx> writes: > It seems that someone has recently decided that GET requests for up2date > ~ make a lot of sense. > > While this is both more efficient in terms of having to read the request > ~ body and having to xml parse it, unfortunately it is not part of the > XML-RPC protocol. > > According to Dave Winer's spec at http://www.xmlrpc.com/spec, and to > everyone else, XML-RPC is a HTTP-POST protocol. > > I appreciate that XML-RPC's file limitations already require up2date to > return non-XML-RPC payloads, but wonton undermining of these protocols > leads us down the path of Microsoft. > > Can we agree that up2date was not designed and developed exclusively for > RedHat environments, and that as such, it's in all of our interests to > keep it durable. > > I can provide you with the necessary patch to fix this if required, but > I'd first like to hear whether or not you'd apply it. Umm... I think you're laboring under some misunderstandings. The GETs in up2dare are completely outside of the context of an XMLRPC request. Nothing about the XMLRPC spec says 'you cannot use GET requests in conjunction with actual XMLRPC calls.' That's like saying you can't mmap a file if you fopen'd a different file. Different tools for different jobs. Moreover, the non-yum/apt communication layer for up2date is strictly for speaking to the RHN servers maintained by RH. It doesn't undermine any protocol or standard if that communications tunnel is XMLRPC, GET, XMLRPC/raw(*), EBCDIC, email, snail mail, ftp, or ICMP echo packets. All of the publicly exposed xmlrpc APIs for RHN (which aren't the up2date APIs) conform to proper XMLRPC requests. This is what matters most to users. (*) - XMLRPC request whose response is raw data, ie, not an xmlrpc response Chip -- Chip Turner cturner@xxxxxxxxxx Red Hat, Inc.
