TIP: Click on subject to list as thread! ANSI
echo: muffin
to: Bob Jones
from: Maurice Kinal
date: 2003-10-08 21:07:40
subject: Long `unzip` time

Hey Bob!

Oct 08 19:20 03, Bob Jones wrote to Maurice Kinal:

 BJ> And here we are straying from what I would define as a BBS....  Yes, 
 BJ> I agree different approaches (browser based, etc.) are needed to get 
 BJ> to the users, but that is not a "BBS" to me....

I could make it look like one.  I mean there are http daemons that could be
used to produce the same interface as any BBS package does.  However, I do
happen to agree with you but unfortunetly those days may have passed us by.

 BJ> And while I agre 
 BJ> that adding a web interface to access what is accessable from Max 
 BJ> (message and file base) would be nice, I do not see it as part of 
 BJ> Max....  Instead the web access should be served up (by an 
 BJ> application running) on a normal (Apache?) web server......

That would be one way but there are other http lightweight daemons that
might be more suitable to produce the oldtime look and feel of a BBS,
Maximus included.  That might be a better "frontend" these days,
all things considered.  The last BBS I ran, DOS Maximus btw, on POTS about
five years ago, was getting one caller who called maybe once a week on
average.  Binkleyterm saw far more action with the Fido host and quite a
bit of local netmail between other local nodes.  But even that has dried up
these days.

 BJ>> I am sure there are many 
 BJ>> users that were not familiar with a given BBS interface when they 
 BJ>> first called one (or more) BBS(es).  This is where 
 BJ>> it was usefull for 
 BJ>> the Sysop to see what was going on with his system.....

Hmmmmmmm.  I am not sure.

 BJ> I think we will agree to disagree....  The sysop console is there so 
 BJ> the sysop *can* see exactly what the user is seeing....

Chat might be more doable but I am fairly sure I would not want that.  :-)

 BJ> Someone comming in as a fidonet point is not a BBS user....  Someone 
 BJ> comming in via a web site is not a BBS user.  Yes, these are 
 BJ> potentially alternate methods of accessing fidonet's information.

That's the basic idea.  Seems that is really all they're after which is why
an offline door would be attractive.
  
 BJ> Max currently does work in conjustion with other tools (via using 
 BJ> squish) for allowing fidonet points to access stuff.

Offline door.  Same basic idea as the point system except packets aren't
created on the fly.  In some ways this is a better idea.

 BJ> And some folks 
 BJ> have integerated web based interfaces to BBS packages.....  While Max 
 BJ> (or a program written to interact with Max) may eventually be 
 BJ> written, that isn't going to be the initial push.  At least from my 
 BJ> view point.  Yes, I may be wrong on where this project will head in 
 BJ> the short term.....  It would be easier (in my opinion) to write a 
 BJ> piece of code to interface a web server (apache) with the bbs 
 BJ> database (echo areas and file areas) than to modify max to also 
 BJ> become a web server....

Personally I like the idea of a http daemon "frontend" if it can
be called that.  I am thinking that it could be used as a go between for a
user's browser and ye ol' Maximus BBS menuing system etc.  I like how the
protocols.ctl is setup to employ other programs to handle uploads/downloads
and I think a small http daemon might be controlled in a simular manner by
Max.  I am still playing with the c-kermit and Max and am having fun with
that.  Maybe there is some simular fun to be had with http?  Just a
thought.

Life is good,
Maurice

--- Msged/LNX 6.1.1
* Origin: LMBrain Pointy System (1:153/401.1)
SEEN-BY: 633/267 270
@PATH: 153/401 307 140/1 106/2000 633/267

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.