[
Lists Home |
Date Index |
Thread Index
]
Paul Prescod wrote:
> Matthew, if it was a case of cleanliness versus ugliness I would
> absolutely agree with you. That's why I haven't proposed a "clean"
> alternative to the SOAP encoding or other uglinesses. The
> issue is that
> one model allows certain types of declarative, distributed XML-based
> applications to be built and the other makes them so costly as to be
> infeasible. When one solution meets requirements that the other does
> not, it cannot and will not go away -- even if the mainstream
> chooses to
> use the less powerful solution. That's why IP was not and could not be
> killed by NetBEUI or IPX, no matter how many corporate
> installations of
> the latter there were. When people realized that their needs were not
> being met they were forced to switch, despite the cost.
Your analogy to IP is well taken, but I still don't understand what your
"declarative, distributed" applications look like and why they can't be
built with SOAP. I'm a huge proponent of declarative approaches to software
development, and I *want* to be convinced.
> I agree. That's why I discourage thinking of web services as APIs and
> encourage thinking of them as writable information resources.
I don't understand this either. Can you tie this into your Google example,
perhaps? It seems to me that we are more talking about read-only resources
that can be manipulated more easily because they provide structured content,
no?
> I disagree heartily. It's a MASSIVE leap forward. Making the data
> available in an easy-to-process form is a really, really
> important first
> step. Nevertheless I agree that it is a first step.
Fair enough, it's a big step forward. Whether it's a "quantum leap" (in my
words) is still a question of what other infrastructure is there to let
people get value from the structured content.
> Even if the technologies available were perfect, I don't
> think that the
> different web sites have much incentive to help you build this
> application. Who will decide what advertisments you see and how will
> they ensure you aren't filtering them out. Maybe if you were a paid
> subscriber to each information resource but that gets quite expensive
> and complicated too...plus they need to worry that you are proxying
> their information to non-subscribers in real-time. Lots of messy
> business issues.
Another good point, but to me this just means that the Web is going to
migrate towards a more business-oriented model where you can do
micro-billing in a convenient way. Obviously this is going to take a while,
but then who is claiming that this web services vision (whatever it is) is
going to materialize tomorrow? (They're out there, for sure, but we're all
smart enough to know they're dead wrong, right?) I'd certainly pay, say,
$10/year each to have access to the four information sources I mentioned, if
I could repurpose the information in the way that I am proposing. This is
probably a far more viable model for making money and providing value over
the longer term than the current advertising-oriented model. Hell, I'd pay
$10/year just to get rid of all those annoying popup windows, and I never
even look at them longer than it takes me to navigate my mouse to the close
button...
> Nevertheless, if all of the information were in XML, and you are
> programmer then of course you can probably build this application in a
> half day or so. That's not as good as point and click but better than
> today's situation!
Agreed.
> There are two parts to your application, in my mind. The first is the
> aggregation of information. The second is the application of business
> rules. The aggregation of information can be done today. That's what
> portals do. Perhaps the purest expression of your vision is
> Meerkat, in
> that it aggregates such a large number of information
> resources. I think
> that HTTP+URIs+XML is indisputably the way to do that part.
I don't think Meerkat is really it, since it doesn't tie the information
sources into each other. This is an important part of what I am talking
about, much more important than the metadata side.
> The second part is the business rule application. This is more tricky
> and I see no reason to believe that web services (whether
> REST, or SOAP
> or whatever) will make this really easy. Vendors tell you differently
> but I do not believe them. We've never gotten to the point where LOCAL
> app building can be done by "people who barely figured out how to turn
> on their computer". Why would it ever be easier to build DISTRIBUTED
> apps? IMO, the best we can hope for is Hypercard or VB or Python or
> whatever you think the epitome of ease of use is. And that's not easy
> enough, according to your criterion.
Probably true, unfortunately. I'm starting to think that what would solve my
use case best for the truly naive user is a form-based interface. Need to
think about that a little more...
Matt
|
