> From: rickard [mailto:[EMAIL PROTECTED]]
>
> [...]
>
> > Imagine if web browsers were implmented with an API
> solution, where the
> > "stubs" had to be implemented as downloadable "C" shared
> libraries. To
> > view a web site, you'd first bootstrap to the site by
> downloading its
> > implementation shared library. Then your browser would load
> the shared
> > library and call the standard API calls. Just imagine the
> flexibility of
> > this system... not being constrained by HTTP or HTML. You could
> > implement some really cool web interfaces this way. But of
> course, this
> > architecture would never be accepted by a broad marketplace. HTTP
> > constrains, but by constraining it also enables. Users don't (in
> > general) have to worry about what web browser will work
> with what web
> > server. All web browsers and all web servers are generally
> expected to
> > work together, because they conform to the HTTP wire protocol.
>
> Thanks for proving my point. See, most of the content in browsers come
> from HTTP/HTML, and this is an a-ok baseline for most people. However,
> if you want more than just the bare-bones stuff on your site you use
> plugins (compare with downloadable stubs), that perhaps use multimedia
> streaming (compare with custom wire-protocols). And all of this is
> possible because HTML allows custom code using custom wire-protocols.
> Which is used on lots of websites to enhance the experience of their
> users.
I didn't prove your point. Plug-ins are generally used to implement
proprietary protocols, and are used for probably about 0.1% of all web
content. I don't know how the 0.1% case proves your point. Yes, you can
go proprietary and require a plug-in... but you'll lose a bunch of your
potential audience, because for whatever reason, they won't download the
plug-in. The other 99.9% is what uses the standard protocols.
> IMHO (and you're free to disagree) none of your points showed
> in any way
> that in this particular case would it be a better idea to use one
> wire-protocol instead of using a (more flexible, IMHO) API-based
> solution.
What I don't understand is why you differentiate server-to-server
interoperability from client-to-server interoperability. It seems to me
that if IIOP is not a required protocol, then this affects the
client-to-server case as much as it affects the server-to-server case.
-eric
