From: petrilli@nextover.pe.utexas.edu (Chris Petrilli)
Subject: Re: Austin Free-net?
Originator: riddle@aahsa.tic.com
X-Submissions: eff-austin@tic.com
Organization: none
Date: Tue, 29 Sep 1992 16:39:20 GMT

>> Austin isn't Cleveland (thank gods for small favors ;-)
>
>Hmm, perhaps we could embarras the City into providing a bit of
>funding.

This is perhaps a good approach, as the City sees it fit to pump an
enourmous amount of money into "non-traditional" project (most of
which I support), I think we might actually have a chance at SOME
money, even if it's only a partial support. Political support is also
worth quite a bit these days.

>> I think perhaps we should look at not an either/or, but a both/and
>> approach as I was taught by people at the MediaLab.  Why limit people
>> to one approach?  Why not give people what is most appropriate for
>> them?
>
>Certainly.  I agree that my mom, were she living in Austin and a
>subscriber to "Austin Freenet", would probably not enjoy dealing with
>'ftp' the program.  But I don't know that this means that she need
>login to a Unix box and be presented with a set of ASCII screens.  My
>mom is a Mac-bigot, but perhaps someone else prefers uSoft Windows.

Well, the problem with this is just what you sighted... there are a
lot of people who use a lot of different machines.  On a daily basis I
use NeXTs (this machine on my desk), Macs, Suns, IBM clones, VAX, etc.
Not everyone has a Mac, not everyone has a PC.  I realise that this is
a large number of people, but there are people who will never own a
high end PC (which is what it takes to run Windows decently), so we
have to consider them.

Perhaps a API interface to the system is called for?  Give people a
menu system for those who want that, and allow creative programers to
write nice GUIs for the BBS (though I hazard to say that I've seen
NONE so far that are decent and work well).  Why not give the user the
following options:

        1. Standard menu interface (Compu$serve style).  This is easy
           to use and familiar to a large number of people, and
           powerful enough that a good number of people will not want
           more than this.
        2. API interface.  This would be a protocol that could be used
           over PPP/SLIP (based on sockets no doubt) that could be
           used to develop more advanced applications.
        3. Shell interface.  This is for the "power user" out there
           that needs to access something more powerful.  I use MH and
           that kind of power isn't going to be emulated well in a GUI
           without a lot of contortions.

>Me thinks it would be much better to obtain or develop a TCP/IP stack
>for the machines in question, and then have a UI built on some native
>windowing system, and present *that* to the user, instead of a set of
>ASCII menus.  Give them both, but let some tiny PeeCee on the other
>end of the wire deal with all the UI interupts.

Well, perhaps, but there are still people who might not have the
hardware to run the software.  Let's be realistic, there ar quite a
few "PC" architectures, and I really thinks it's absurd to try and
keep them all in parallel development (anything else would be
favoratism and not fair to anyone).

>I don't know how POP is limited for this case.  I'm of the opinion that
>its one of the few places where POP will fit.  There is no IETF WG on
>remote mail access, only a (lately) very quiet mailing list.  Note that
>I'm not saying that POP is the perfect rmap, but it does seem to deal
>with mailbox transfer very well.

Perhaps it's not the protocol itself but I've seen no implementations
so far that seem "built" to handle the kind of use we're talking.
Cleveland Free-Net has about 9,000 users, I suspect we could garner
double that without too much trouble.

And I believe there is the beginnings of a Remote-Mail working group,
but I could be wrong, I've stayed away from the IETF politics of late
and have been busy working on code for other projects.

>> Also, as a member of the Pip Working Group (proposed IP7), I think
>> some stuff will have to wait till early next year, since that is the
>> earliest a definitive decision will be made on what the IP4
>> replacement will be. I *HOPE* Pip gets the nod, as I think it's the
>> technologically superior system, but we are in a crunch to do real
>> world work right now.
>
>I'm holding out for SIP.  I'll not voice my opinion of PIP here. :-) 

Unfortunately it seems everyone has their own proposal (even in the
Pip group), so I don't know WHAT will get supported.  

>Even if PIP (or SIP) is chosen next year, it will be another two or three
>years before the Internet can even think of cutting over to the new
>protocol.  I *personally* remember the night of the NCP->IP cut, and
>DARPA no longer has operational responsibility for all the routers.

I remember the cut over as well, and it'll be 1000000x more complex
this time, if only because there are a few more than 200 hosts *smirk*
:-)

Anyway, I think we have to be careful in what we are doing, and going
"commercial" is a dangerous game.

Chris


Newsgroups: austin.eff