[standards-jig] JEP 65 - Bytestreams

Ben Schumacher ben at blahr.com
Thu Dec 19 21:09:22 UTC 2002


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jan Niehusmann wrote:
| I got many complaints by users who said that our mail server was
| extremely slow. In all cases, these users missconfigured their personal
| firewalls to discard ident requests instead of answering them or sending
| a RST, so the SMTP server had to wait for a TCP timeout. Some of them
| where unable to correct that problem.
|
| So I think configuring a jabber client properly would be too difficult
| for these users. They just don't understand IP networking.

Jan-

I'm sorry, but this "issue" just doesn't carry water, in my opinion.
There are several reasons for this:

1) It is your *job* to support these users. Whether or not you like it,
it is what you get paid to do. The simple solution is to place a FAQ
online for your customers to read, and that they can find the answers to
why my Jabber client isn't working.

2) Do you think your users will be any happier with software that
doesn't seem to work at all, because of bugs (edge cases) introduced by
the increased complexity? Will they be happier with software that
crashes occasionally when they are trying to establish these direct
connections, because an edge case has been hit where the client is in an
undefined state? While making software easy for users it preferred,
introducing complex state machines for this reason benefits neither
users, or developers. Users can be educated -- all it takes a little
diligence and patience. Overly complex software is a nightmare for users
and developers. Have we learned nothing from Microsoft?

3) What do you do in the case of a client doing HTTP polling? When I'm
using HTTP polling, I'm making a new connection with each poll. I am not
guaranteed to be always accessing from the same IP address, not to
mention that I never really know what IP I am connecting from, since
dynamic routes could change this for me. How do I tell the far end which
IP to connect to? Do I just listen on *:4321 and then use some sort of
OS-level call to see what IPs my box has? If my machine is multi-homed
on several connections, I could be passing several IPs, some of which
will be impossible for the far end to route to. How does the client know
which is the preferred IP in this case?

In the end, a user changes one option, once. If we really want an
alternate solution for this, I would propose some sort of client-server
negotiation on connection to figure out if the client can accept
incoming connection, but ultimately, this could fail, as well. The
client could even say, "Connection timed out. -- This could be because
you, or the far end are behind a firewall." That way, while it may take
a timeout the first time (a one minute delay isn't so bad), in the
future a user will have the knowledge of what the problem may be, and
future connections won't have the same problems.

Cheers,

bs.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE+AjV9UpoGqensAXIRAvxCAKCOwNyYSEAQ/pzTKhhcSrkq/ZXp4gCgsz/n
t9GZCrIkmgJwVUAPi96GYHE=
=4c6Q
-----END PGP SIGNATURE-----




More information about the Standards mailing list