[
Lists Home |
Date Index |
Thread Index
]
Micah Dubinko wrote:
>
> HST. I like that. I still find it hard to believe that all the complexity of
> SOAP+WSDL+UDDI (or pick any other acronyms from the list [1]) is a net
> benefit. Or a Net benefit.
How about XForms? ;)
Standards are like social programs. People always want to fewer of them
until they want one more.
>...
> 1. Define a layered system, where the simple cases really are simple
The simple cases really are simple. You can use XML-RPC. Or even better,
XPC:
* http://www.focusresearch.com/gregor/sw/XPC/XPC-0.2.html
Or just HTTP.
> 2. Defend the complexity they introduce; explain the phenomenal benefits
> that more than offset the complexity
Every feature exists because somebody asked for it. That person will
scream that the benefits are phenomenonal. Exactly like public programs.
I don't think there is any easy way to separate the wheat from the
chaff. Sometimes really smart people totally misunderstand the
cost/benefit ratio of a feature.
I'm not saying that complexity is not a problem. I'm saying that I don't
know of a systematic way to reduce it other than "being vigilante." Once
you figure out the right amount of complexity you can apply that
algorithm to governments and we'll all pay the "right" amount of taxes
for the "right" set of social programs. Slowing down helps, because
people get experience before standardizing. But industry screams when
things slow down because they have to ship product.
> 3. Work with vendors to produce useful tools for "hooking stuff together"
> with XML (including "low-tech" methods like XMLchucker or XMLbaton)
I don't understand how much easier you expect things to get. You don't
need any new standards to do XMLChucker or XMLBaton. Here's a rough
start to my "xmlchucker.py". Finishing it (checking error conditions,
adding FTP support, etc.) would take about an hour:
import urllib, httplib, urlparse
from xml.dom import minidom
def fetch(uri):
return minidom.parse(urllib.urlopen(uri))
# todo, add streaming support...three lines
def chuck(uri, xml):
scheme, location, path = urlparse.urlparse(uri)[0:3]
if scheme=="http":
conn = httplib.HTTPConnection(location)
conn.request("PUT", path, xml, {"Content-type": "text/xml"})
elif scheme=="ftp":
pass # todo
elif scheme=="file":
pass # todo
def remove(uri)
scheme, location, path = urlparse.urlparse(uri)[0:3]
if scheme=="http":
conn = httplib.HTTPConnection(location)
conn.request("DELETE", path)
elif scheme=="ftp":
pass # todo
elif scheme=="file":
pass # todo
def fetch_and_remove(uri):
dom = fetch(uri)
remove(uri)
return dom
def test():
print fetch("http://www.constantrevolution.com/content.xml";)
chuck("http://www.constantrevolution.com/otherstuff.xml",";<foo/>")
Maybe you had more in mind for XMLChucker and XMLBaton but it seems to
me that they are already trivially solved by the widely deployed specs
we have today. Giving them formal names and specifications just confuses
the specification landscape further, in my opinion.
Or maybe XMLChucker is supposed to be a streaming XML where events are
XML elements, rather than full documents. In that case you could juse
use Jabber, which uses exactly that model.
Paul Prescod
|
