Nicely described Ian. At least someone doesnt rubbish SMTP/POP with
glib 'email is just not efficient' or 'just isnt robust' arguments!
We have and do work in both environments (we did the HIC messaging in
the Authority Prescriptions project using HTTP) and we are using Web
Services for some functions (minor at this time) in Argus and we still
have a lot of respect for the email system for its sophistication,
infrastructure and dependability. We also know its limitations.
I just get tired of the techo nay-sayers who knock SMTP/POP because they
have latched onto the 'latest and greatest' and discard the old.
Still, HTTP + Web Services looks promising.
cheers
Ross Davey
Ian Haywood wrote:
On Monday 13 November 2006 22:41, Richard Hosking wrote:
http is a "handshaking" synchronous protocol with 5 steps back and forth
between the client and the server to complete a transaction.
client queries server
server acknowledges
client acknowledges
data sent
client/server acknowledges no of bytes - resend if error
You are describing TCP which is common to both SMTP and HTTP.
No store and forward mechanism is required. In this day of broadband
most surgeries can be online continually so it isnt an issue
Few surgeries have static IP, so running a reliable server is still hard,
(your server briefly goes down every time your IP changes, haywood.bpa.nu
experiences this about one a week) and violates the user agreement of many
ISPs. The need for store-and-forward is not going anyway for a little while
longer.
By contrast e mail is asynchronous - the packet of data is simply fired
off into space in the hope it will reach it's destination.
No, SMTP is a direct connection to the server and clients get an
acknowledgement just they do with HTTP.
SMTP would have about the same level of overhead or less as an equivalent HTTP
service.
The problem is, that SMTP allows store-and-forward, but it doesn't *require*
it, and most people use this feature rather than running their own server.
Using a direct HTTP ("web-service") or a direct SMTP connection both solve
this problem and neither has a particular advantage from an end-users
perspective.
Most importantly, if you implemented store-and-forward with HTTP, which you
could, and probably would have to, you would get all the disadvantages of
SMTP, having done a lot of extra work.
The electrons don't magically become faster or more reliable with HTTP.
However, SMTP has several practical advantages for a developer
- it's an existing, proven standard, for web-services we would need a new
standard.
- standard extensions for encryption and acknowledgement, again, this all
needs to be defined from scratch for web-services.
- the biggie: it's linked to the MX feature of DNS, this allows you to attach
several servers, potentially in different locations, to a given address, if
one fails the clients trying to connect will automatically switch to another,
providing guaranteed uptime. [telstra's mailserver does not use this feature]
- there are existing free libraries 'off-the-shelf' for all this stuff
- yes you can use the ebXML standard over HTTP to do this. Prepare to spend a
lot of money. Oh, and did someone mention overhead ;-)
Ian
------------------------------------------------------------------------
_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
