Text 5660, 110 rader
Skriven 2006-04-11 23:45:44 av Maurice Kinal (1:140/13.1)
   Kommentar till text 5659 av Stephen Haffly (1:396/45.27)
Ärende: PPoint in Linux
=======================
Hey Stephen!

Apr 11 05:11 06, Stephen Haffly wrote to Maurice Kinal:

 SH> What it has is a database and an index for each area along with the
 SH> interface to tie it all together.

For that I would be tempted to use perl as the basic functionality of perl is
easily portable, even to/from Windows, despite differences in how that is
actually accompilshed.  However on the downside of that is not many Windows
boxes have perl available to them.  Given that then portability is a difficult
issue between unixie and more dos-ish systems.  Not ever having to concern
myself with that is probably why I tend to favour unix now that dos is no
longer a concern.  As far as networking with windows boxes that is far easier
as long as the software running on the linux box doesn't concern itself with
having to run on the windows box (or os/2 for that matter) and only concerns
itself with compatibilty of input/output, such as in the case of html.  Note
that file names on a linux server have absolutely no effect on them being
viewable on a web browser no matter what the OS the browser is running on. 
Files on a server with a whole mess of dots in the name (eg
whatever.weirdness.someone.likes.to.do.with.periods) as a filename on dos
systems is impossible but they can read/write to them simply because they
aren't local to their machine.

 SH> It also has the ability to do 
 SH> daily
 SH> maintenance by age (or to delete messages flagged for deletion) and 
 SH> to
 SH> print those messages selected for printing.

Printing could, and perhaps should, be farmed out to whatever is responsible
for lp.  Not really an issue in linux.

 SH> It has several drop-down menues.  On the HOST menu, it scans for new
 SH> messages, zips them into a packet, connects (transfers control to
 SH> whatever program is being used to connect to the boss node, in my 
 SH> case,
 SH> IREX) for mail transfer.

A number of options open there, including text and gui based libs and/or
scripts.

 SH> MAIL has the functions for read/write/export/delete/print/search
 SH> messages.

Could easily be farmed out to a script.

 SH> OPTIONS has a shell to dos for quick command line needs, and most
 SH> important, a function to back up and restore the message databases.

Personally I have six virtual cosoles going on at any given moment. 
commandline accessibilty is a non issue and has been since day one here.  :-)

 SH> Here one can edit taglines, print the user manual, or start the 
 SH> manual
 SH> processing of packets if one downloaded them by other means than 
 SH> through
 SH> the HOST transfer.

Hasn't been an issue here.

 SH> SETUP has all of the functions for making it work such as configuring
 SH> for hardware/printer/directories as well as for area
 SH> addition/deletion/modification (such as number of days before old
 SH> messages are automatically deleted).

Most of that happens at bootup here.  I don't have or use a printer but would
set that up for ALL utilities that need it at bootup.  Another nonissue.

 SH> It has a basic manual nodelist 
 SH> so
 SH> a limited number of entries can be made.

That could be done, but not really needed between a point and host.

 SH> The menu system can be navigated by the keyboard with no mouse needed
 SH> (although it can be used).  The editor is user selectable.

Right.  That would be nice.  vim would be my first choice.

 SH> It was only for an emergency use.  I'd rather not use it again.

Not many are using qwk ... not many using fido either anymore.  Definetly
accessabilty and compatibilty may be the main reason for that.  I am not aware
of anyone in these parts using noramlly fido connectivity software, such as
zmodem and the such.  These days web browsers seem to get the highest marks as
far as home based users are concerned. 

 SH> I know that each of the functionns can be done by a Linux program.  

Yep.  Has been that way since day one.

 SH> What
 SH> I don't know is if there is an interface to tie all of the functions
 SH> together into one package.

A number of them ... perhaps too many of them.  :-/

 SH> I don't care as much if behind the 
 SH> scenes,
 SH> different programs are doing the work.  If that is doable, then I am
 SH> interested.

For sure it is doable.  All it takes is someone(s) to make it happen.

Life is good,
Maurice

--- Msged/LNX 6.2.0
 * Origin: The Pointy Stick Society XVIII - Don't know what I want (1:140/13.1)