Text 761, 94 rader
Skriven 2007-03-25 09:50:34 av Peter Knapper (3:772/1.10)
    Kommentar till text 757 av Maurice Kinal (1:140/13)
Ärende: Fidonet URL syntax
==========================
Hi Maurice,

 PK> By putting Fidonet message bases directly on the 
 PK> internet without the 
 PK> management environment of a BBS to "control" the 
 PK> user, the quality of 
 PK> content will become questionable (at best). 

 MK> I mostly agree with that assessment except that there 
 MK> are methods where users known to the sysop can connect 
 MK> via an internetted connection and it is essentially the 
 MK> same as a dialup connection.

I guess the prime issue I have here is that the management wrapper around the
internet environment just doesnt seem to lend itself to the method used on a
BBS. EG here, ALL callers to my BBS get read-only access first call, but if
they want WRITE access, then they have to leave personal information that I can
manually validate before write access is given. This approach works because a
BBS caller is (usually) local to me, and thus the volume is low so the process
is managable, but with internet access... all bets are off. I just dont see how
we can practically expect this level of management to be applied to an internet
world, and the moment you lose that the quality goes down and thereby the value
of the content.


 MK> The first terminal based BBS I ever used was a networked one - not 
 MK> positive if truly internetted since it was before 
 MK> public access and I happened to be on a box already 
 MK> connected on a LAN that had access to the internet but 
 MK> the BBS was also on the same LAN - and access was 
 MK> either telnet or rlogin or something along that line.  

That brings back memories, I used to use a local *nix based messaging system
with internet connectivity via an accademic environment, long before public
internet became available to the masses.......;-). It was a local BBS that had
quite an active user community of Geeks and Nerds hanging out of every nook and
crany. Thre were quite a few bright sparks around those days, and many of them
still exist locally.


 MK> I have 
 MK> telnetted to quite a few lately over the internet and I 
 MK> still see little difference.

From those visits, can you see an approach that could be applied to HTTP based
access, that provides the management arm of BBS type operation? I have long
pondered this issue but I just dont see a realistic method appearing, not
because of a technology shortfall, but simply because of the geographic
dispersion of end users and the "validation" methods that are acceptable. 

Oddly enough it was Fidonets "non commercial" environment that allowed such
controls to (reasonably) effectively operate, something which the commercial
internet world always had issues with managing to the same level. In many ways
the internet world as we know it today is a haven for anarchists......;-)


 PK> If Fidonet wishes its content to continue to mean something, then it 
 PK> really does need the BBS interface methodology to remain exactly as 
 PK> it is now, IE restricted to authenticated and managed users.

 MK> I agree with that except I personally don't like 
 MK> browsers, nevermid IE, and would likely opt out as a 
 MK> sysop of a web based BBS nevermind a user.  

I agree, Fidonet is about a textual user interface, not graphics. As long as we
dont loose that from our sites then Fidonet can still work. 

One way this may be able to work is to add the ability of attaching a POINTER
in a message (a URL if you wish), such that a reference can be made to
graphical content, but that graphical content should NOT become part of the
textual message itself. I am still not convinced that this approach is even
viable...


 MK> I still 
 MK> give terminal based applications the edge, especially 
 MK> if I am a user.  That hasn't stopped me from using the 
 MK> internet especially considering it is my only connection at the moment.

Since I started using Maximus/2 V1.03 on a 286 under OS/2 v1.3 I have used
Maximus/2 to read and write messages. I have not seen a need to change that
(yet). 


 MK> However I'd rather see nothing change then adding more 
 MK> silliness without getting rid of the old silliness.

We are actually much closer in our thinking that it first appeared....;-)

Cheers..............pk.


--- Maximus/2 3.01
 * Origin: Another Good Point About OS/2 (3:772/1.10)