Re: protocol explosion (was asynchronous execution, was Re: implementing a set of queue-processing servers)

Rob Nagler wrote:

>  
>
>I'm not advocating this.  Rather, I am recommending using a
>well-known, and arguably the most widely-used protocol:
>application/x-www-form-urlencoded--and it's near cousin
>multipart/form-data.  However, that's messy, we can just call it HTTP,
>and our implementation is LWP and Apache.
>  
>
>  
>
>>At least with J2EE, for every major standard or protocol
>>implemented, there is only one way to do it.  With Perl, you
>>actually have more confusion because there are many more ways to do
>>it. More ways to do templating, more ways to do middleware, more
>>ways to do serialization of objects, etc...
>>    
>>
>
>There are equivalent number of ways in both languages.  If you are
>saying that you could build a "standard component" in, say, EJB, and
>sell it, well, that's just not the case.  That's the pipe dream of
>CORBA.  The only thing close to portable protocols is HTTP.  Sabre,
>for example, gives you a library, and you have to interface to it.
>However, authorize.net's interface is HTTP, and I can write my own
>library in < 100 lines of Perl, which matches my application, and
>doesn't require me to install anything.
>
>There's such a thing as standard protocols, but every application uses
>them differently.
>
>  
>
I disagree. I think it depends on the protocol. A well designed protocol 
for an application will spread and stand the test of time. Sometimes the 
protocol doesn't have to be well designed, but just that it's standard 
can help tremendously.

eg if we were a world that said HTTP is "it" and we should do everything 
over HTTP, then would you really see SMTP over HTTP? SNMP over HTTP? 
telnet over HTTP? Why?

This doesn't really make sense to me.

While it's nice to think that it's fun to write a protocol over HTTP, 
different protocols may be designed for different reasons. In the case 
of RMI for Java, it is really primarily a serialization issue than a 
protocol issue (in fact it is supposed to be implementable over HTTP to 
go through firewalls). If I have a Java front-end and a Java middleware, 
I much prefer using RMI for expediency than having an HTTP based 
protocol like SOAP.

But whether you agree whether you like a given protocol or not, my 
primary points are that

a) I don't think it is fair to pick on Java specifically for the number 
of protocols when there are equivalent and arguably greater "explosion" 
of protocols in the CPAN.  

b) If you don't use "standard" application-layer protocols, then you are 
actually creating your own protocol explosion but just with fewer users 
using your own proprietary system over HTTP. So in a way it is a matter 
of semantics.

I find it hard to agree that it is always a good idea to create your own 
protocol all the time if others exist that are published and even more 
importantly, documented. I think it depends on your project or product 
that you are developing.