marcvh
|
|
Remote PicoSpan posting?
| 
Jul 3 15:39 UTC 1995 |
OK, here's a nice half-baked proposal for an enhancement to Grex...
I'd like to see a mail daemon for posting responses (and maybe items)
in conferences. I believe this would improve convenience for
Internet-link users and make more effective use of our limited link
bandwidth and machine resources.
Currently, reading items is a bit slow and tedious at times if the
link bandwidth is slow (and ping times are running around 5 seconds)
but it's doable. Entering responses, however, is a royal pain. A
trivial response is just slow and annoying to echo characters, and a
lengthy response (i.e. more than 2 lines) is virtually impossible.
This is not even mentioning the load imposed on the system by users
running the "Emacs Makes A Computer Slow" editor, which fills the link
bandwidth with screen updates and bogs down the system.
As I compose this item, I'm typing in an XEmacs window on my local
machine while my telnet link to Grex sits idle; this is good for Grex
and more convenient for me. However, when I want to actually enter
this response, I am forced to either:
- FTP the file to Grex, then enter it manually. This is slow
(sometimes incredibly slow, with FTP transfer times on the order of
3 bytes per second.)
- Cut and paste the content into my telnet window, if I'm in an
environment where I can do that. This works, but is hard to do with
larger chunks and sometimes words get dropped or truncated.
I would propose a system whereby, instead of any of these kludges, a
remote user could simply mail the response to some daemon, say
something like:
To: picospan-entry@grex.cyberspace.org
Subject: coop 70
Yes, I know that mail is traditionally a resource hog, but in this
case the cost of receiving a response via mail is much lower than the
cost of receiving every keystroke and edit in its own individual TCP
packet.
Such a system would, alas, probably be somewhat subject to abuse. I
don't think the problem is any more dramatic than current
vulnerabilities, but it is there.
|
zook
|
|
response 1 of 5:
|
Jul 4 02:09 UTC 1995 |
Wasn't there a discussion of line-buffering vs keystroke-echoing earlier?
I like the sound of a mail address for sending in responses, but perhaps a
line buffer might be better suited as a solution? Perhaps I should not
stick my nose in, not being UNIX-savvy... <zook sticks his nose in
anyways> I thought the major points of said discussion was that either/or
could be implemented, but not both. Telnetters would do better with line
buffers, but direct dialers would do better with single-key echos... Would
it be possible to set up a split system?
|
srw
|
|
response 2 of 5:
|
Jul 4 05:18 UTC 1995 |
Email is easily forged, so this would make conference entries just as
forgeable as email. It's tougher now, but I don't think that is a
strong enough reason not to do it.
Somewhere in the mail-to-picospan gateway you propose, there should be
a check made to see that at least the mail came from an approved
origin site. You could even insist on a HELO response to cut down
the ease with which it could be forged.
One big difficulty is the attachment to Picospan, itself.
Picospan is not designed to be run from anything but an interactive
terminal. You'd have to have a script that fooled it by using
(presumably root) authority to su to the posting user before
starting picospan and piping the post to it. Picospan keys off of
the uid it is run as.
This sounds possible, but I have never written this kind of thing.
|
steve
|
|
response 3 of 5:
|
Jul 4 23:30 UTC 1995 |
It's definately doable; Remps was written quite some time ago,
which is the PicoSpan end of it--the front end would have to be
changed, but it could be done. I guess the big question is, should
we want to do this? Unforuately, I see a nice large, fat juicy
"way" of people to cause problems on Grex. Not that they couldn't
anyway, by logging in and doing the same, but this way we've automated
the ability for harrassment in PicoSpan.
Probably this biigest thing about this is the fact that we don't
have anyone free enough to do it--there are lots of things on the
plate that are more urgent.
|