|
Grex > Coop11 > #58: the unofficial grex-related discussion. share what you care. | |
|
| Author |
Message |
| 10 new of 34 responses total. |
spiff
|
|
response 25 of 34:
| 
Dec 20 08:12 UTC 1998 |
agreeing with #24, would like to add that i meant (and it should be
obvious) all basic e-mailing functions should be made available. and
what about the telnet gateway? anybody sympathise?
|
remmers
|
|
response 26 of 34:
|
Dec 20 11:39 UTC 1998 |
The easiest way to make mail functions available "via the web"
would be for Grex to offer POP service. Technically I suppose
it wouldn't be "web" because it would involve the pop3 and smtp
protocols rather than http, but that's a technical distinction
that I suspect would be immaterial to most users. As mentioned
earlier, we haven't done POP, the concern being that it would
encourage too much using Grex *just* as a mail drop. Granted,
a lot of people do that anyway, and contend for the telnet queue
in the process. POP would sidestep the telnet queue, just as
backtalk does, so making it available might make telnet queue
waits shorter. There are valid arguments on both sides about POP.
(Re-thinking what I said earlier yet again - making simple mail
reading, as opposed to full mail functionality, available via the
web would be extremely easy, unless I'm missing something.)
|
cmcgee
|
|
response 27 of 34:
|
Dec 20 18:26 UTC 1998 |
For those of us who occasionally try to retrieve email while away from A2,
simple reading would be helpful. I have found it easier to get web access than
to get telnet access when visiting friends and relatives.
|
mikeg
|
|
response 28 of 34:
|
Dec 20 19:49 UTC 1998 |
re: spotty telnet gateways
There are some decent Java telnet apps out there, one of which is GPL'd
and available at http://www.first.gmd.de/persons/leo/java/Telnet/.
Would this be a viable solution? (A user who has telnet blocked could
use the Java telnet instead, provided they had a browser that supports
Java)
|
mta
|
|
response 29 of 34:
|
Dec 21 02:19 UTC 1998 |
When I'll be away from Ann Arnbor, I have my e-mail forwarded to a web-based
e-mail system like hotmail or Yahoo. That way no onme has to learn a new
address for me and I can remove the forward when I return if I want to.
|
spiff
|
|
response 30 of 34:
|
Dec 22 05:57 UTC 1998 |
good suggestion. i did that. (#29)
|
rtg
|
|
response 31 of 34:
|
Dec 22 06:43 UTC 1998 |
re: resp:27 Both IE and Netscape browsers have a builtin
telnet client, and WIN95, as well as WFWG 3.11 (with the free TCP/IP
extensions) come with telnet clients. The AOL client does telnet, as
well. I've never had trouble finding a telnet client on any machine that
has been set up for internet access of any kind.
re: resp:28 A telnet client implemented in JAVA is still a telnet client,
and will communicate using telnet protocols, not http protocols. So the
user will still have to wait thru the telnet queue, and once they're
logged on, they'll have to suffer with the higher resource utilization and
slower performance of an interpreted client rather than a
natively-compiled one.
|
dpc
|
|
response 32 of 34:
|
Dec 22 15:32 UTC 1998 |
We are *losing* people to our conferences because they decline to partici-
pate in the telnet queue. If people who only use us for e-mail weren't
on Grex, the queue wouldn't be needed.
|
jiffer
|
|
response 33 of 34:
|
Dec 22 19:05 UTC 1998 |
I think that most people who use the telnet que have an internet connection,
so, they can always use backtalk if the que is too long. It is what I use.
It is also (IMO) alot easier to use because the buttons and such are *there*
if they need help, want to change something or have questions.
|
mdw
|
|
response 34 of 34:
|
Dec 22 21:01 UTC 1998 |
If the people who only want e-mail didn't have to wait through the
telnet queue, but could use a standard web browser instead, the # of
people using grex for e-mail would skyrocket, and eat up considerably
more computing and network resources on grex. If our only means of
adjusting load on grex is to adjust the # of people who can telnet in at
once, that means we'd have to drastically reduce that number, which
would likely mean an even longer wait through a much slower and shorter
telnet queue, and a considerably more sluggish system.
|