Re: SMTP slow???

[rsedc@xxxxxxxxxxxxxxxxxxxxxxx (David Chia)]

> Actually, my studing of HTTP (sniffer traces and the like) has shown me a
> model for using HTTP for "direct control".  This involves doing the client
> thing directly (unless the browser has good APIs).  The server as is, even
> the CERN server has what it takes to run the translator.

The industry trend is that the off-the-shelf web browser will become
the universal front end across all OS's and HW platforms to many if not
all applications such as DBMS, email reader, etc. The
EDI-translator/server can be such application which can also
communicate directly (as client) to the TP's http server.

Modern http servers and browsers can even have additional functions
directly embeded into them, functions such as script/byte-code
interpreter, DBMS, encryption modules, expert systems, etc, so that the
use of cgi process can be reduced if not eliminated.

The browser is used to control the server, e.g. to determine
if the transaction is in real-time or in batch mode,
using http, ftp or smtp. The server will handle the transactions,
auto-initiate, auto-retry or auto-response, or the more intelligent
tasks like 'find out who makes widgets today and select the best three
quoatations'. Of course most of the transactions will be using EDI :)

> We did a simple proof of concept.  If you'd like I can find out if I can
> send the HTML, CGI and C stuff to the list.  No shots allowed at how very
> rough it is.  It was done to see if the protocol works as we thought.

It would be nice if a public test-bed is also available.
The handling of NRO, NRR, etc needs to be standardised
(at the MIME level or lower?) and common to http, ftp and smtp.


David Chia,
RMIT University