Re: EDI over http?

["Matthew James Gering" <mgering@xxxxxxxxxxxx>]

Indeed, a http server is not by default also an http client, but it is
trivial to make one so -- all proxy servers are both http clients and
servers. But the point is irrelavent, http, smtp, ftp and other internet
protocol client libraries are widely available and trivial to implement.

I think "real time SMTP" or psuedo-realtime -- something that at least
handles fowarding and queuing, would be the best.

Although I entirely agree that a simple open internet-based protocol should
be used for for EDI for interoperability and low implementation cost, I
don't think an appropriate protocol exists.

Personally I'd like to see the inclusion of some transaction-related
functions such as are included in more advanced computer-to-computer
messaging systems such as Microsoft's MSMQ/MTS, IBM's MVS/CICS and
MQSeries, etc. But perhaps this just shows my limited understanding of the
EDI process itself.

	Matt

----------
> No I don't think you are missing anything here. My point was that
> whether we adopt a "real time SMTP" as Carl Hage suggested, or use HTTP
> POST over SSL, some amount of server side implementation is required. I
> thought some of the discussion was assuming that you get HTTP over SSL
> for "free", when you use a web server.
>