
Friday 05-Mar-93 15:57:38

--750--
BA> Display-Flags shown while scanning your mail...
BA> 13) "U" carbon copied from a Usenet sub
BA> 14) "D" download-able file attached
BA> 15) "R" you already read the actual post in the subs
BA>          (In case you want to avoid re-reading this carbon copy)

I forgot one:
16) "A" you already answered (replied to) this letter.

Also...
Should CNet be removing the 'new-mail "*"' marker:
1)  After you read that piece.
OR
2)  After you run and exit MailRead (MR).
    (Regardless of whether you read that new piece or not.)

It appears to be doing #2 currently.

Currently, if you read some of your mail, but don't get a chance to
read it all (for whatever reason), then next time you run MailRead,
the system no longer marks it with "*".  (But they do stay marked "*"
if you've already read them, but haven't exited MR, yet.)

Should his change to #1, instead?
Are 1 (or a more) of the 16 proposed scan-markers needed?

In an ideal world, EVERY caller should read ALL his mail, on EVERY
call, to EVERY CNet he calls, reply fully to EVERY piece, and
afterwards delete it ALL.

I wish EVERY caller did this.  (I wish *I* did this.)
I wish it was always feasible to do.

But things come up...
You can't respond because a user's mailbox is full.
Little or no time to respond.
You have to get back with an answer after you check something else online.
System events coming up, online time limits, etc.
High phone bills, easier/cheaper/quicker to write a reply offline and call back.
Saving mail for reference purposes.  (I still wish we could quote from
                           multiple emails, as we now can from multiple
                           posts.  For EXACTLY the same reasons.)

I don't mind users keeping a few (or many) pieces of mail in their
boxes.  'Space' shouldn't be too much of a problem.  CNet already does
a nice job by only allowing each caller to save x bytes of mail.  Cut
him off anywhere you see fit.

I think a few of these proposed flags would actually REDUCE a user's
old, saved mail.  He'll see (at a glance) exactly which pieces are
old-unread/new-unread/old-read/new-read/replied-to/not-replied/just-
carbon-copies/junk-party-mail/file-mail/etc.  And can better kill.
(A "K3" or "K2,4,6-10" would also help.)

> Cleaning out your mailbox..
As with many things regarding BBSing...
You can try and FORCE a user to do something.  OR
Just make it so simple, so fast, and so straight-forward that they
will WANT to do it.  There'll be no reason not to.

--751--

L> L> SG by#12  or RA byenforcer
L> Maybe a SG '#12' or something?
L> or RA 'enforcer'

The single quote char is already reserved for 'titles' scanning.
(And I hope it always stays as such.)

But I do feel that CNet's TOME and BYME options would have been
much better as just TO and BY options.  You could follow them
by any name/handle/ID# you wanted.  Yours or anyone elses.

1) I would love to read/browse/yank everything posted here by Ken, Jim,
Shawn, Don, etc, in 1 quick shot.  It would be some incredible reading.

2) Also, if you had a user that had been posting garbage msgs, trying
to trash your msg bases, you could quickly find everything he posted.
Try doing either of those things now.

I mentioned this to Ken as of Oct 1992.  If he doesn't add it in 6 months, I
don't know if he's going to.  Am I the only person that sees the value and
power of #1-2?

--752--
>Supporting IBM cursor movements for VDE usage...

What about supporting other machines too?
Amiga/IBM/Mac/Atari/C64/Apple2/Unix/etc?
And a handful of different terms on each of them, each that
translates/filters those keys into different key-codes?
What about visual-text editor support?
What about visual-data editor (VDE) support?

> EP
> 13) Edit SIGNATURES                     14) Edit "WHO" BANNER
> 15) Edit MACROS                         16) Define KEYCODES
> 16
> Hit your DELETE key now:
> Hit your BACKSPACE key now:
> Hit your CLEAR-SCREEN key now:
> Hit your CURSOR-UP key now:
> Hit your CURSOR-DOWN key now:
> Hit your CURSOR-LEFT key now:
> Hit your CURSOR-RIGHT key now:

All machines (even 1s that haven't been designed yet), and all terms
(even 1s that haven't been written yet), would always be 100% compatible
with CNet's (and 3rd parties) VDE and vis-ed.

Of course, you wouldn't have to edit these at all if you just wanted
to use the current, default, Amiga keycodes.

Do you want CNet to be compatible with SOME terms, and SOME machines?
MOST terms, and MOST machines?  Or 100% compatible with ALL?
90% is 'great'.  (Unless you are using 1 of the 10% not-supported
terms or machines.)

Is it worth all this extra work?
When you are calling in from remote, stuck using 1 of the non-
supported machines, or using 1 of the non-support term-translations,
and your ability to run ANY VDE (or fullscreen text editor) is NULL.
Then YES, this is important!

--753--
> struct MainPort {       /* common, public to all ports */
>    struct   MsgPort mp;    /*   0 standard EXEC message port  */
>    char  portName[22];     /*  34 */
>    char  LastOn[32];    /*  56 */
>    long  Nums[5];    /*  88 # of accounts, etc */
What are each of these 5 Nums?  (I found #-of-calls-to-system, but
can't figure out the others.)

>    long  SAM[5][15];    /* activity monitor  */
And which of these 5, holds the 15 "LAST" variables?

BA> long  SAM[5][15];    /* activity monitor  */
BA> And which of these 5, holds the 15 "LAST" variables?

KEN> [0][x] I think...

// That's what I thought.
// The code below correctly shows ALL values as they appear in "AM".
// EXCEPT [0][x]. They are always all 0s.
for(i=0; i<5; i++)
   for(j=0; j<15; j++)
   {
      sprintf(buf, "SAM[%d][%d]=%d \n", i, j, myp->SAM[i][j]);
      PutText(buf);
   }


KEN> Maybe z->SAMNow[]

--754--

I'm working on my own VDE.
"ABC:" would be the text explaining each field.
"1234567" would be a numeric variable, a max of 7 chars.

When I have 4-5 of these per line, the mouse-gadgets-clicks
seem 'overrun' into the next field.

ABC: 1234567   ABC: 1234567   ABC: 1234567   ABC: 1234567
ABC: 1234567   ABC: 1234567   ABC: 1234567   ABC: 1234567
ABC: 1234567   ABC: 1234567   ABC: 1234567   ABC: 1234567
^                ^
|    field 1     |
                  ^                   ^
                  |     field 2       |
(NOT drawn to scale.)

I've had to put A LOT of spaces between fields to avoid this
conflict.  (So many so, that I can't even achieve my desired layout.)

Shouldn't the 'hit area' ONLY be:
ABC: 1234567   ABC: 1234567   ABC: 1234567   ABC: 1234567
^          ^
|          |

Or maybe:
ABC: 1234567   ABC: 1234567   ABC: 1234567   ABC: 1234567
^   ^
|   |

(Or does VDE impose a min allowed length of "ABC"?  Mine being too short.)

How is VDE determining its 'gadget-hit area'?

KEN> Thanks, found it, I had it hard-wired to 21.

So which one are you going to go with?

1> Hardwired 21 chars wide.

2> ABC: 1234567   ABC: 1234567   ABC: 1234567   ABC: 1234567
2> ^          ^
2> |          |

3> ABC: 1234567   ABC: 1234567   ABC: 1234567   ABC: 1234567
3> ^   ^
3> |   |

I like #2.

Is this for a v2.70 6-week release?
Or a v2.62 sooner release?

KEN> #3, Soon.

I was hoping to have VDE do things with very short (or even NULL)
description-string strings.

Like edit a few of the most common variables for multi access-groups,
at once.  These would probably need style #2 instead.  (As well as
give ALL VDE's a larger hit-area.)

VDE>                               ACCESS GROUPS
VDE>                  0    1    2    3    4    5    6    7    8
VDE> Calls per day:   3    4    5   10   15   20   30   40   50
VDE> Mins per call:  10   20   30   40   50   60   70   80   90
VDE> DLs per day  :   1    3    5    7    9   11   15   20   30
VDE> ULs per day  :  10   20   30   99   99   99   99   99   99
VDE> Use JoinLink :  No   No   No   No   No   No  Yes  Yes  Yes
VDE> Send BulkMail:  No   No   No  Yes  Yes  Yes  Yes  Yes  Yes
VDE> etc

Only the 1st column has a description-string.  The others would be
reached by cursor-movement or a mouse-click (onto the variable itself.
No description-string for these.)

I also need to have VDE display a description-string ONLY.  (ie: The
"ACCESS GROUP" shown above.)  Maybe a new VDEEntry "type" field for
"display description-string only"?  (For titles, and also great for
displaying helpful reminder-text about the VDE, too.)

--755--
Would anyone have a use for a 'roll-over purge' flag in each sub?
When a sub hits its max-limit, then (and only then) would each new
post, delete 1 oldest post.

Users would never get a 'sub-full' msg.

No amaint purging.

A 300 msg max sub, would ALWAYS stay at 300.  NOT slowly dwindle to
250, 200, 150, if amaint deletes old msgs faster than the new posts
are occuring.  (You can't always guess at keeping these equal.)

Users would always have a max # of msgs available for reading.

Just because a msg hasn't been responded to recently, doesn't mean
it isn't great info and should be deleted.  (Especially when no one
is trying to post anything new here, anyway.)

Works great for file-purging, too.

The # of old, deleted files will always = the # of new uploads.
Automagically.

> 1 response...
I'm surprised you and I are the only ones that I've ever seen mention
this problem.  I think EVERYONE (whether you have 20 megs or 1 gig)
would be facing this problem.

Even the largest of HDs fill-up, eventually.

Even the most liberal 'purge-date' setting (90-200 days) could
eventually, totally EMPTY your harddrive of ALL msgs.

Even the most strick 'purge-date' setting (1-5) could still fill
your HD and forbid all new posts.

How do we accurately 'guess' at a date setting where POSTING will
always equal (exactly or approximately) PURGING?  With roll-over, it
would be automatically equal.  Each 1 new post would replace each 1
old post.

You couldn't guarantee the exact same msg sizes, but I think in a sub-limit
of 300 items, #1 would forever stay MUCH closer to the same size HD space used:
1) the roll-over sub ALWAYS stays at exactly 300 items.
2) a non-roll-over sub with a purge-date (set to anything) would fluctuate
   between 0 and 300 posts.

If posts average 15-20K each:
#1 would fluctuate between 4.5meg-6meg.
#2 would fluctuate between 0meg-6meg.

If ULs average 80K-100K each:
#1 would fluctuate between 24meg-30meg.
#2 would fluctuate between 0meg-30meg.

Quite a difference in HD space-management.

I'm suggesting the PURGE-DATE and ROLL-OVER flag should work TOGETHER.
(SysOp could use either, both, or neither.)

--756--
When you SCAN your mail, are (or should) they be listed oldest to newest?
Seems like when I hit a certain # of pieces of old mail, some new mail
started appearing as #1,2,3 again.  (And afterwards, more new mail
started appearing at the bottom of the list.)  After reading, they all
get marked as 'old' mail but continue to appear out of (date) order.

Or is this the way it works?

(I started reading mail #1, not realizing it was sent *AFTER* #2, etc.)

So reading new mail is: 1,2,20,21....
Easy (but odd) with "*" markings in place.

Impossible after the "*" clear themselves.  (ie, after I run, then exit
MR")

I'd like to see everything just come in as 1-n.

--757--
GV>  thinking of waiting for 3.0 (C-Net) to come out... because of the IFIDO times
GV>  etc. I'm sure he'll find a better way to index into the message files.

I don't think it's a IFIDO 'index' problem.
It's a IFIDO 2-step Bundle -> FidoNet Format -> CNet Format problem.
Instead of a 1-step Bundle->CNet Format.

I've NOT seen anything from Ken regarding improving it for v3.0.
(Or ever.)

In fact, no comment from him that IFIDO even NEEDS any changes.

You better speak-up, if you think there's a speed problem.
(I, and several others, already have.)

--758--
I can't imagine how ANYTHING 2-way ("2 transfers" or "1 transfer while
chatting/searching/reading/etc") can be done without ALL being present:

1) A Term that allows this.
   (How will it know that it should be prepared to accept and save
    incoming files, while asking and gathering outgoing files?)

2) A protocol that allows this.
   (To actually do the transfers.)

3) A BBS that allows this.
   (How will it know to allow marking and sending of incoming files, while
   receiving and correctly placing incoming files?)

Sound correct?  (I wish it was as simple as dropping in a new protocol,
regardless of whether or not the TERM and BBS are prepared to start
sending/receiving 2-way.)

Unfortunately, who will coordinate the 3 different authors so that
things can be agreed upon?  And who will be first?  Will Ken wait
until #1 and #2 are available?  Will Ncomm/JrComm/Term authors wait
until #2 and #3 are available?  Will all the XPR authors (if it's even
possible) wait until after #1 and #3 are available?

Who will get the ball rolling?  The "Other Guy"?

I'll be happy to contact as many BBS/XPR/TERM authors as I can
find.  But what do I tell them?  I've never written a BBS, XPR, or
a TERM, and don't know the 1st thing about what is needed.

Maybe some one will gather a list of Names/Phone #s/Fidonet address of
several different TERM and XPR authors.  Join it together with my list
of 25-50 BBS authors.  (Along with this item's text.)  And EVERYONE
can help forward the whole thing to TERM/XPR/BBS authors everywhere.

After that, it'll be upto those authors to get something started.
Or not.

And I think 1000s of people asking for a 2-way protocol, would
show authors this is not something that just 5 callers want.
It could literally cut $1000000 off phone bills, worldwide.

--759--
You probably already know, but, your system just gave me...
>NOTE: can not find "SysText:menu/olm" ...

--760--
>I need a 2-way protocol.  How?
That is the $64,000,000 question.

I think we first have to get ahold of people that know what they are
talking about.  (2-way protocol rumors and fake 2-way protocols run
rampant.)

If you have PERSONALLY (not rumored) done ALL (not some) of the
following:

1) A simultaneous 2-way FILE (not chat&file) transfer.
2) Used an Amiga on BOTH ends.
3) Done it BBS<-->Term.  (NOT Term<-->Term).

Please reply with:
A)  What protocol was used?
B)  What BBS was used?
C)  What Term was used?

Is VBBS the only Amiga BBS package (out of 58 thus far) to have done
all 1-3, EVER???

--761--
Ken, when I do a ZIP UPLOAD of text into CNet's full-screen editor,
all text is appended onto the end of my current text.  And I have
to do a cut/paste afterwards.

Anyway to have the ULed text inserted at the current cursor position?
(Like it would be if I just started typing it in by hand.)

--762--
I guess the LHA release was removed.

It had a few problems:
1)  It was different BBS executable than the DMS release.
2)  Had a bug or 2 that the DMS didn't have.
3)  Both different versions were called v2.61.
4)  There were a few files in the LHA that were NOT different than
    the last release.
5)  There were a few files that WERE updated since the last
    release, that weren't included in the LHA.

100s of SysOps may now be running 2 different v2.61 releases.
(I bet not many of them even know it.)
Which 1 are you using?

Of course, this was NOT done deliberately on Ken's part.
#1-3 were accidental.
#4-5 just forgotten/overlooked.

But the 261_d1.DMS and 261_d2.DMS should still be available.

--763--
How do I get BBSMENU to limit certain cmds to certain access-groups?

This works:
BBSMENU> STatus                        `23

This doesn't:
BBSMENU> MYpile | {#3pfiles:MyPfile}   `23

--764--
When I hit [S]can at the "Respond or pass" prompt, I'd love to see
"(RECEIVED)" or "(REC)" or even "(R)" marker next to each date.

Right now we have to scan, then read, scan & read, scan & read to find
out which responses have been received.

Do you really want to kill an item that still has 94 'unreceived' responses?
How can you QUICKLY tell?

DM> I have maintenance set on most my local subs to 15 days, if a users
DM> doesn't care to call and read any responses that may be waiting for him
DM> within that two weeks, then I have no problem with deleting "unrecieved"
DM> reponses..

This was mainly for 'by hand killing', not auto-maint.
(If you are about to UL a newer program and wish to delete the old one,
and all its responses.)

As well as just for a quick, 'who has/hasn't read their posts' viewing.
(You might even find that *YOU'VE* accidently skipped reading a few
posts addressed to you.)

"Calling daily" doesn't mean you read everything in every base.
(Many SysOps like 'carbon-copy' turned OFF.  I don't know why, it
uses minuscule amounts of disk-space.  A duplicate 'copy' is NOT made
of all your msgs.  Just a very small, pointer file.  Sure wish it had been
called 'waiting-mail ON/OFF' or some other name.  It might be used more.  It's
a great way to encourage 'replying' and more active msg bases.)

Don, do you find the (RECEIVED) marker in the full-header useful?
I do, VERY much.
That's the only reason I reall suggested it be available in [S]can, too.


R> I HAD carbon copy on but MOST of my uses HATED seeing mesg twice, once in
R> Email and again when doing a read of all new mesgs.  Don't your users
R> complain about seeing everything twice?

Twice?
With CNet I'm forced to read many things 3-4 times.

I post a reply.  I immediately have to read it at the respond/pass prompt.
I call back tommorrow, I read it again with RA.  (MY OWN MSG!)
I call back again the next day, I read it AGAIN as a 'lead-in' because PREVIEW
is turned ON.  (Only the sysop can control this, not the caller.)
If at any point I need to do a 2nd RA during the same call, I re-read
EVERYTHING yet again.

If I keep my local-screen open/logged-in at all times, "RA" will
make me re-read everything, over and over again, forever.

If the SysOp (callers can't control it) has Copy-Carbon turned ON for
that base, I run the risk of reading all replies addressed to me,
once during my log-in mail read, and then AGAIN when I read the
bases for new msgs.   (Now I've lost track of how many re-re-reads
that is.  But anything more than 1, is too much.)

I've made suggestions to Ken, regarding handling this matter.
No comment from him yet.

Maybe some per-user flags could be added.  (4 bytes can store 32 new
flags.)  Does anyone like/dislike 1 (or more) of the following?

CNet> "EP"
CNet> 15) Edit MACROS                16) Configure USER flags
CNet> 16
 1) Do you wish to preview 1 previous msg during new-scans:
 2) Do you wish to preview YOUR previous msg during new-scans:
...
...
...
16) Skip Mail-Read of carbon-copy items already marked RECEIVED:
17) Receive carbon-copies of local posts:
18) Receive carbon-copies of Fidonet posts:
19) Receive carbon-copies of Usenet posts:

DM> I had the same complaints about messages that were in my local subboards..
DM> I however found that my users really loved the "carbon copy" feature for
DM> the fido subboards.  Almost to a person they didn't want the local
DM> subboards "carbon copied" but they did want any messages addresed to them
DM> in fido subboards "carbon copied" to their mail boxes..

See #17-19 (or 180 other user-flags in my MASTER.LHA file.)

--765--
I still wish anyone that had 'kill any UL' or 'kill own ULs' power
would get 2 prompts when 'killing':
> Kill the full item text [Yes]:
> Kill the attached file [Yes]:

1) If you answered YY:  It would remove both.
2) If you answered YN:  It would remove just the text.
3) If you answered NY:  It would remove just the file.  The item would then
   become a 'post-only', non-file type.
4) If you answered NN:  It would remove neither.

1,2,4 are already available, except #3, the biggie...

We've had to fully delete some pretty great, lengthy discussions just
to remove the attached (outdated) file.  (Or updated, outdated, buggy,
corrupted, virused, etc.  I WANT users to still be able to READ about
these.)  What a waste of good info.

The lack of #3 also creates the very common "what happened to that
file", that we often see.  (Even here on Future World, often.)

--766--
After I use CNet's VDE to change some values in one of CNet's
structures, how do I force CNet to re-write that data to disk
immediately?

(CNet may or may not do so on its own, before or after the next
caller, or before the next reboot, but I want to make sure my changes
get saved to disk NOW, instead of 'soon' or 'maybe'.)

Also, how do I guarantee this 'write-to-disk' for non-VDE pfiles, as
well?  If I change one the variables in the current ItemType3
structure, how can I force a re-write to disk?  (It'll NOT be
preserved otherwise.)

Is some kind of WriteToDisk(BYTE type_num) available?
(Where type_num is 1-10 for user-data, msg-data, subboard-data, etc.)

More later...

I have a ton of unfinished tools and pfiles.  If *ALL* need to re-
write any data they modify, I'd like to just get the full list of
"CNet structs VS filenames" from you.  But, if you want me to bother
you 1-by-1, I one...  Here's 1 of the simplest examples I could find.

C>    ((z->Item0).DLnotifyULer) = !((z->Item0).DLnotifyULer);
C>    PutText("\nNotification-bit successfully toggled.\n");
C>
C> sprintf(buf, "\nThe uploader is %s each time this file is downloaded.\n",
C>                       ((z->Item0).DLnotifyULer) ? "NOTIFIED" : "NOT NOTIFIED" );
C> PutText(buf);

It's part of a pfile that allows ULers to toggle the DLnotify flag on/off.
(Does the above code look correct?)
It works fine.
But how do I re-save the info to disk, after the toggle?
I'd MUCH rather instruct CNet to re-save it, and NOT have to do it
myself.  (For easy, safety, and conflict reasons, as well as 100%
future compatibility.)

Would it be feasible to add to CNet something like:
> #define USERPORT_WRITE         0x00000001
> #define MAINPORT_WRITE         0x00000002
> #define CURRENT_ITEM_WRITE     0x00000004
> #define CURRENT_RESPONSE_WRITE 0x00000008
> ...etc...
> ...etc...
> BOOL WriteData(LONG which);

and our pfiles could just call WriteData(CURRENT_RESPONSE_WRITE).
(Regardless of updates/changes to CNet.)

Response...
Try PutItem(z->br)

Are we going to see a call-back for PutItem()?
Could it be s-q-u-e-e-z-e-d into v2.62?

Are call-backs for other 'write structures to disk' planned in the future?
Without them, A LOT a stuff (100s of variables) gets tricky (or near
impossible) to do correctly.

The big ones:
MainPort UserData MailHeader ListItem PortData

or:
Config1 FileType SelectType BaseUser HeaderType MessageType3
ItemHeader ItemType3 NewSubboardType AccessGroup MarkType

--767--

R> SO, i want to write my own tosser, but i need the *.pkt specs... Can
R> anyone help?
R> Also, isn't it about time Ken does a direct *.pkt to Cnet-style message
R> base tosser?? (Tfido?) :)

R> Bill, i think i saw you mention on the CNet-echo you'd be willing to write
R> this.. Still up for it?

Get me the FULL *.pkt specs and the FULL CNet specs/docs and I'll let
you know (within 1 hour) whether or not it is something I'll have the
time/know-how to tackle.

(I can't imagine it being any more difficult to do than IFIDO itself.)

With the full docs, I think you'll see SEVERAL I/XFIDO alternatives
pop-up.  (Am I correct in assuming there are currently 0 choices?)
(You know how I hate 0 choices. :-))

Everyone can start posting suggestions NOW:
  What would you like I/Xfido to do, that it currently can't?

(I was interested in mainly, reducing its 2-step process down to 1-step.
And just cloning all the other features.)

Ken, would it just be absurd of me to ask you to release the C source?
(Not to me, but to everyone.)
That would be 90% of the battle.

--768--
On Sat 13-Mar-1993 12:34a, Upsmatic Noman wrote:
UN> 2. Change the MCI {w} command to wait 1/10 second instead of 1 second.
Didn't the old MCI have this?  I can't find it.  I guess not.
If Ken is going to change it, he should do it quickly.  (Before 1000s
of MCI files are counting on this being x secs, not 1/10th secs.)

UN> 4. How about a command like yank that will pack a SCAN of a subboard?
How about an additional special keystroke similar to "!".

Any cmd ending in "&" would spawn a background task and email you the results.
Any cmd ending in ">" would spawn a background task and bundle/mark for DL.

Then instead of just allowing your 1 suggestion, *ANYTHING* could be packed
for DL.
 FIND ThisThat >
 FINGER Bill Allen >
 INFO >
 SN >
 SG >
 SA >
Gfiles, News-files, the text for 1 response (a biggie), ANYTHING putting out
text would be redirected, marked and Zmodem DLable.

--769--
I wouldn't suggest BIG changes in CNet's messaging methods for things that
can already be done.  (Or for things that could be added, while keeping
CNet's current methods.)

R> If you read a mesg that is a response to
R> another mesg you can type T for Traceback and it will show you the
R> original
R> mesg.  This almost completely eliminated quoting.
Ken could add this to CNet's current msg methods.  I'd like it.

R> Another feature was that if someone left you a mesg in a public base
R> you would be noticed on logon
Like CNet's carbon-copy?
(Yes, it should be made 2-ways smarter.
A)  Allow the caller (not the sysops) to turn this on/off.
B)  If the user reads his carbon-copied version, then skip the re-read
    in the bases.  (And/or vice versa.))

Other than the obvious different thread-read (which is a matter of
personal taste), list a few OTHER things the CNet's current method
can't do.  Maybe we could have the best of both worlds.  (And WITHOUT
another big msg-base reformatting upgrade.)

R> It cuts down on the need for quoting    DRASTICALLY.
I haven't used offline readers.
How well informed would those users, be with little or no quoting?

R> Example.
R> User 1 types a long question
R> User 2 replies 'yes'
R> User 1 is TOTALLY lost until he threads back to the original mesg (one
R> key press)

I thought we were talking about changing the entire format of CNet's
current methods.  No?  Which?
1)  Post an item, all replies still appear attached to that 1
    item, but sorted by reply-threads, instead of the current date-sort.
2)  Changing everything so that items are all reply-threads.

I'd be in favor of #1.  (If "EP" had a "Reply sort" variable.  BY DATE or
REPLY THREAD.  A single global setting for each user would be fine.  NOT
another variable to set for 100s of subs individually.)

But I'm against #2.
(Which are we discussing here?)

But heck, I can't even get Ken to change the reply header into:
CNet> On Sun 14-Mar-1993  4:10a, Rock wrote in reply #297:
...                                                   ^^^
...
We could always re-read the original post for more info than
what's in the quote.  (Reply-threaded or date-sorted)

--770--
Different people have different definitions of the phrase "BBS with
Usenet Support".  My definition includes ALL 3:
1)  An included, custom, frontdoor (written specifically for the BBS)
    to get/send UUCP bundles.
2)  Usenet msgs right in the normal BBS msg bases.
3)  Hierarchy msg area lists.

Other definitions can include:
4)  Use a universal, 3rd party frontdoor, NOT specifically written
    to work 100% with your BBS's specific features.
5)  Usenet support by running (3rd party or included) a separate, external
    shell or door.
6)  Linear 1-by-1 msg area lists.

MANY BBSes can be forced (some easy, some hard) to do Usenet if your
definition includes 4-6.

There's just NO reason for a 1990s, state-of-the-art BBS package, on
an incredible machine like the Amiga (68000-68040), to NOT do #1-3
these days.

A recent telecomm magazine claims there are over 2,500 Usenet echos,
50,000 Usenet systems, and 30,000,000 readers worldwide.  It makes
Fidonet look like a flea-speck.
Yet many Amiga BBS packages support Fidonet, instead.

How many support #1-3 in full?

--771--
Ray, would you be interested in using a simple compression method
for your spell-checker's dictionaries?
(And still shave a whopping 50%-80% off the size!)
(As well as having a giant PD dictionary available for use!)
(As well as keeping them text-based and still human readable!)
(As well as a speed increase.)

The text-editor UEDIT & its dictionary are now public domain.
(Including full source.)

Its dictionary files use things like:
smart#er#est#ly#ness
small#er#est#ness#pox#time

The word "small" (and all its possible suffixes) are listed, but the baseword
"small" appears once instead of 6 times in the dictionary.
5 chars instead of 30.  83% savings.

Also, I have a list of the 1200 most common words in the English
language.  Search these before the 'full-dictionary' and you'll get
a LARGE # of near instant 'hits'.

--772--

Is everyone getting this "?"-line with v2.62?

CNet> More responses. Respond, Pass, or ENTER to continue> r
CNet> Publicly respond to "Random Cnet Q&A, Part II":
CNet> Anonymous [No] N
CNet> ?
CNet> Address this to John Doe [No] N

--773--
Here's a FULL way to do it:
Have the file structures allow about a 20-25 char filename.

Each file-area can be set by the SysOp to 1 of 3:
1)  Allow ULs of any filename lengths.
2)  Chop to 8.3 IBM filenames.
    (With a VERY CLEVER algorithm.  NOT just 'chop-it'.
    But rather, preserve the .EXT.  Remove vowels until the basename
    is 8 chars.  Remove 1 more vowel and append 1 2 3 4, as needed,
    if it duplicates an existing file.
    All still recognizable offshoots of the original filename.)
3)  Forbid non-IBM filenames.
    ULer's will be asked for a 8.3 filename.  Otherwise, no UL.

Each user's account has a matching variable for DLing:
A)  Allow any filename lengths.
    (Amiga's and other non-IBM users will DL filenames 'as-is' online.
B)  Chop to 8.3 IBM filenames.  (See above method.)
C)  Prompt user for a filename right before the DL.

-Fulltime Amiga users (ULers and DLers) (8.3 or 20 char lovers) are happy.
-Fulltime IBM users (ULers and DLers) are happy with their 8.3 limits.
-Parttime users of both machines can alter their "filename variable setup"
 to A or B at anytime.  (Or use C for a 'one-shot' IBM DL.)
-BBSes can have separate #1-3 settings for EACH file area. (IBM file-areas
 don't limit Amiga file-areas.)
-Upto 99 duplicate ULs without filename conflict due to chopping.
-All 6 #1-#3 and #A-#C settings use less than 1 byte of HD space per area
 or per user.
-It addresses SysOp-concerns as well as caller-concerns.

I know of NO Amiga-BBS that does this complete method.

No SysOp or Caller filename limits (or desires) would be left-out.
If it's missing anything, please let me know.

This needs to cover A-L-L bases once and for all.
Once *FULLY* addressed, Ken will never need address this question again.

--774--
>Message #431 "Nat. CNet-BBS Echo" (Read: 6)
>Date: Fri  5 Mar 93  1:13
>From: Carl Tashian
>  To: All
>Subj: {v1}
>
>does anyone have an ARexx function to change the output of {v1} (last
>call date) to the number of days since the user's last call? I am
>working on FileList, and I would like to have the default number of
>days for making a [N]ew file list be the number of days since the
>user's last call..  anyone? I know this is possible, and i'm pretty
>sure it's been done, but it's a little too tricky for me to write!

I just wrote one.
Carl, it's online at Ken's BBS @ 313-981-6150

--775--
I'm seeing MANY msgs about IFIDO taking 1-2 hours to process mail.

>Without Ken having any Large Fido ECHOS on his system he will never
>experience the horror of waiting 2 3/4 hrs to IFIDO.. so he will put
>the needed speed up on a back burner.. On paper his current IFIDO
>processing must look good to him but when he goes Fido (if he gets a
>few large volume Echos like Politics and Teen) he will make it top
>priority to do something about it!! But if he doesn't get some large
>echos he may never make a chang! So it will be up to us to push him
>into realizing the pain of the IFIDO wait!
(I've removed the original poster's name.)

Approximately how many msgs per minute are *YOU* seeing processed with
IFIDO and XFIDO?

If it's doing less than 30 msgs/min, it's too slow, in my opinion.

(If we estimated the above anonymous user had processed 1000 msgs in
his 2.75 hours... that would be 6 msgs/min.)

Can someone run some 'msg-count' VS 'time' benchmarks?

DM> IFido to import all the messages was less than 16 mins..  Total messages
DM> imported was 1738 messages..  These figures are straight from my Foozle
THANKS!
Can someone list a few reasons why other users are getting 5-10msgs/min
processed VS your 109msgs/min?  Something must be VERY wrong for a 10x-20x
difference occur.

That was on a 68030/25mhz?

I might add, I really just wanted to benchmark XFIDO and IFIDO speeds,
NOT TrapToss, Fozzle, etc.  I realize they reflect the overall time,
but Ken can't do anything about speeding those up.  Just his code.
(Another disadvantage with relying on 3rd party coding.  Speed, bugs,
updates are totally out of his control.)

Ken, please consider adding to the X/IFido log output:
> 14-Mar  4:20a  IMPORTED:          123 msgs in 2:21 mins (55msgs/min)
> 15-Mar  4:43a  EXPORTED:          293 msgs in 3:55 mins (73msgs/min)

--776--
LH> The VBBS home BBS has a large international following even with it's
LH> unwieldy interface.... It simply doesn't cost that much extra to use...
Define "large following"?
How many VBBS are in use worldwide?
How many non-VBBSes?
How many callers are using the VBBS-Term VS a non-VBBS-Term?

I just can't get excited over a 100% non-compatible, proprietary
graphic interface.  (Especially with VBBS methods, where it also
FORBIDS anything but that 1 interface be used.)

I CAN get excited over 3 methods:
1) Basic ANSI-Mouse support.  You click in your term (from remote) to
position the cursor right were you want it.  (In the VDE, full-screen
text editor, command line, etc.)

2) Further ANSI-Mouse support.  Point&click on a SysOp-designed menu
choice to execute it.  Point&click on CNet generated menus ("EP") or
submenus ("EP's submenus").  Point&click on a filename to select it
for DL.  Point&click on a user's name to mail him.  Point&click on
"WHO's" output to CHAT that person.  Etc.

3) You open up a side-panel window in your term.  (It can be as simple
or as fancy, colorful, graphic as you like.)  You click on its [WHO]
gadget, "WH" is sent out the ser port.  Click on [TIME], "TI" is sent.
Click on [STATUS], "ST" is sent.  (You would decide what the gadgets
say, and what chars are sent.)

(Of course, none of the above, would hamper standard ASCII BBSing in
any way, if the user has his user's "Mouse-Support" flag turned off.)

CNet currently supports 0 of the 3.  (It would be much simplier to
support 1-3 of these than to have Ken install a full, custom, non-
compatible, graphic interface or SkyPix.)

--777--

I just finished a C-pfile that allows the ULer themself (right after they UL
or anytime afterwards) to turn that file's DL-notication flag ON/OFF.

I'll UL it within the next 12 hrs.

It can block auto-email per user AND per file.

So do we still need a blocker-flag added to CNet?

Maybe so, but only for those that want to quickly, permanently block ALL
DL-notification mail.

If 1 of your ULs gets DLed 47 times, another 56, and another 32, that's
A LOT of mail to find next time you log-on.

But I do like the "notification" as well as the "see your credits grow" idea.

Maybe have CNet wait and send the notification on the 1st DL, but
only every 10th or 20th DL after that?  (Showing the accumulated 10x credits.)
(Or maybe logarithmically 1/5/10/20/50/100/400...)

It's a shame to give the user 2 choices:
1)  Absolutely NO mail from ANY UL.
2)  154 pieces.
instead of:
3)  A reasonable 3-5 pieces.

(Although, I'm sure some users will be happy with #1-2.  #3 is much more
user friendly.)

--778--
L> Seems once you clear there select list (even if nothing in it), it
L> cures the problem.
Is this a bug?  (A need to clear a select list that is already empty.)
How can I see this bug appear?  (Step-by-step example.)

--779--
AK> 1) I noticed that in TREM mode the MAXIMUM amount of selected files to
AK>    upload is 20, even though in the CONFIG file, I have Selected Files set
AK>    to 40. Why not raise this to at least MATCH what is in the config file.

What's the greatest # of files the avg person ULs at once?

If they match, and you don't want callers to UL >10 files at once, then you'll
be limiting YOUR term-UL ability to 10, also.

1) Restrict callers batch ULs.
2) Restrict the # of files you can UL while using the term.
These are NOT the same thing.  I don't see a need for #1 to exactly equal #2.

--781--
> CNet Auto-ULing...

If this includes the ability for callers to just start sending files,
at any time, at any (nearly) prompt, and STILL have CNet go through
the correct sequence of prompts afterwards.  (To whom/alias/private/
short/long filenotes/etc.)  (CNet would, additionally, need to ask
"which sub?".)

I'M ALL FOR IT!

No more excuses about "I couldn't figure out how/where/when to UL" or
"it's too hard".  (I'm sure some of these users are genuinely
confused.  But others are not.)

Just start sending at anytime.

No special "auto-UL" term needed.

> CNet would, additionally, need to ask "which sub?".
Or maybe not, with a new CONFIG variable.

CONFIG> Default Auto-UL sub: 37
All auto-ULs go directly to this default physical sub #.

(Or set it to 0, if you wish the user to be asked "which sub?".)

Even if Ken doesn't want to go with the "Auto-UL" idea, making the
"UPload" cmd available at ANY prompt, would help.  (It's currently NOT
even available from ANY of the ROOT (or sub-root) UD-base prompts.)

The easier/faster/clearly it is for users to UL, the more ULs you are
going to get.

--782--
Does anyone know how to scan a list of items/files and just see
each file's header info?

> item:
> file:
> from:
> to  :
> on  :
> info:

(But NOT read (or be asked to read) the 1-200 responses that might be
attached to EACH item.)

10 good pieces of info there, just in the header.

Maybe a new option for read/scan/browse:  HEADERS.

--783--

> MultiMail (MM) just keeps looping, asking for subject.

W> Don't you have to specify the name of the file as the subject?
W> Subject of this message: DH0:Blah!

Works here too.

Ken, it is WELL worth having 2 separate lines in BBSTEXT for this.
1> Enter Subject:
2> Enter FileName:

Ask "Attach a file?" first.
Then ask #1 or #2, as appropriate.

(If fact, it might be worth having both available.  It's a shame to
entire forbid #1, whenever you want to use #2.  (And vice-versa.)

--784--
> *Subboard: Upload base/CNet AMIGA SUPPORT/Suggestions for the future
> *Subboard: Upload base/CNet AMIGA SUPPORT/AREXX program files
> *Subboard: Upload base/CNet AMIGA SUPPORT/C program files (2.x)

Ken, I *LOVE* this new display.
I always had trouble finding my way back into deeply nested dirs.
No more.

Will this be an MCI code (hopefully)?
Will a 2nd one be available and expand into "2;6;12;43"?
(After all, that's what the user will need to type to get back to it.)
(Or maybe an MCI with the sub #s appearing before each sub name.)

Also, I think the "Upload base" part can be dropped.
(I hope users will, at least, know that much.)

--785--
Here's a proposal for auto-filenoting.

1) A user ULs 3 files (batched) named FOO.LHA, FOO.note1, FOO.note2.

After the upload is complete, if CNet finds '*.note1', it's used for
the short description and '*.note2' for its long description.  (The
prompts for descriptions are skipped entirely.)  Afterwards, the 1-2
temp "*.note" files are deleted.

2) (Optionally, these "*.note" files could be included right in the
archive, itself.  The SysOp's TRANPOSE scripts would be responsible for
extracting them.  CNet would use them for filenotes, same as above.)

It would in no way interfere with the current method, which would continue
to work as-is.  (SysOps wouldn't have to support method #2, if they didn't
want to.)

The changes Ken would have to make to CNet would be minimal.  Just
have CNet look for *.note1 and *.note2 and use them as the file descriptions,
if found.  That would be about it.

Saves answering short-note prompt, running editor, writing by-hand
online, or uploading/importing text, saving, answering long-note
prompt, running editor, writing by-hand online or upload/importing
text, saving.  (And I think users would write more informative
descriptions, if done off-line.)

Personally, I'd use this feature HEAVILY.  (Method 1 for DMS files,
and method 1 and 2 for LHA files.)  EVERY UL I make to EVERY CNet would have
these pre-written *.note files.

UL 3/6/9 files, batched.  Afterwards, you are right back at the prompt.  Done.

--786--
Who knows the difference (or relationship) between ACCT #s and ID #s?
Where is either used?
1)  Online for MailSend, Finger, etc
2)  For their Mail:User/# dir
3)  For element in SysData:bbs.udata + other data files
4)  Shown with getuser 40 or 41

What would cause these to be the same?
What would cause them to be different?
How do I determine 1, if given the other?

--787--
>ADS & SAN...
Could I get *1* volunteer to place a few of my pfiles/tools in it?
(Mail me first, I'll tell you which ones are ready to go.)

--788--
Ken, I just UL'ed a file called HydraKit.LZH.
It's the full specs and C source to a true, 2-way protocol used
in the IBM world.  Since there aren't too many Amiga BBSes and Terms
running ANY 2-way, this might not be a bad place to start.

--789--

Here's a proposal for auto-filenoting.

1) A user ULs 3 files (batched) named FOO.LHA, FOO.note1, FOO.note2.

After a batch upload is complete, if CNet finds '*.note1', it's used for
the short description and '*.note2' for its long description.  (The
prompts for descriptions are skipped entirely.)  Afterwards, the 1-2
temp "*.note" files are deleted.

2) (Optionally, these "*.note" files could be included right in the
archive, itself.  The SysOp's TRANPOSE scripts would be responsible for
extracting them.  CNet would use them for filenotes, same as above.)

It would in no way interfere with the current method, which would continue
to work as-is.  (SysOps wouldn't have to support method #2, if they didn't
want to.)

The changes Ken would have to make to CNet would be minimal.  Just
have CNet look for *.note1 and *.note2 and use them as the file
descriptions, if found.  That would be about it.

Saves answering short-note prompt, running editor, writing by-hand
online, or uploading/importing text, saving, answering long-note
prompt, running editor, writing by-hand online or upload/importing
text, saving.  (And I think users would write more informative
descriptions, if done off-line.)  Less time tying up the BBS.

Personally, I'd use this feature HEAVILY.  (Method 1 for DMS files,
and method 1 and 2 for LHA files.)  EVERY UL I make to EVERY CNet
would have these pre-written *.note files.

UL 10-20 files, batched.
Afterwards, you are right back at the prompt.  All filenotes,
short and long are done.

--790--

Who knows the difference (or relationship) between ACCT #s and ID #s?
Where is either used?
1)  Online for MailSend, Finger, etc
2)  For their Mail:User/# dir
3)  For element in SysData:bbs.udata + other data files
4)  Shown with getuser 40 or 41

What would cause these to be the same?
What would cause them to be different?
How do I determine 1, if given the other?

--791--

What happened to FW's conference help screens for noises?
"=" "YYY" used to list them and tons of info.

--792--

R> How can you hate this?  It was an OPTION on every mesg, NOT the rule.
How will the 'option' feature work?
A msg will be designated as a 'threaded-type'?
The user's acct will have a 'threaded option' set?
The ORder for each sub (per user) will be settable as 'threaded'?

--793--

Ken, I just [S]canned this item and got:
256 Bill Allen           Big Brother          Tue 15-Dec-1992 12:25a *R*
257 Bill Allen           Big Brother          Tue 15-Dec-1992 12:25a *R*
258 Bill Allen           Big Brother          Tue 15-Dec-1992 12:25a *R*
259 Bill Allen           Big Brother          Tue 15-Dec-1992 12:25a *R*
260 Bill Allen           Big Brother          Tue 15-Dec-1992 12:25a *R*
260 Bill Allen           Big Brother          Tue 15-Dec-1992 12:25a *R*
261 Bill Allen           Big Brother          Tue 15-Dec-1992 12:25a *R*
262 Bill Allen           Big Brother          Tue 15-Dec-1992 12:25a *R*
(Many of those names and date are wrong.)
I scanned it again, and all was fine.

It did it again.
Looks like only when I do a s1-.
The repeating lines start occurring at response #19.

KEN>  This post item is damaged.  I need to delete it, but haven;t because it
KEN>  contains much useful information!
KEN>
KEN>  If you read the entire item, it will begin to repeat at about response 50 over
KEN>  and over again.  Sigh!

Or maybe this 'damage' was done during the msg format conversion?

I'll start a new item.  Ken, you can keep this online as long as you wish.
Would it be fixed if you just deleted 1-100 responses instead of the whole
item?

--794--

Ken, I have the C source you released long ago for "WHO".
Please consider releasing the current source also.
Thanks

--795--

When a user uses EDit to (actually) change the address of a response, CNet
needs to clear the (RECEIVE) marker.
(We currently can make things look like they've been read by people that have
never seen them.)

Also, if I re-address a post, would it also be possible to remove
the copied-carbon the original addressee got, and create one for
the new addressee?

--796--

PB> It seems to me that you are asking for an option for the user to decide
PB> whether to use the advanced Thread based Flag system or choose the more
PB> archaic WWIV read by date submitted and try to keep track of 50 different

Now I've lost track of what I have/haven't asked for.
I'd be happy with 2 additions:
1)  The Quote-line reading
    On Sat 20-Mar-93 10:22p, Pete Baker replied to msg #203 with:
                                                   ^^^^^^^^
    Quick finder.
2)  Hit a new cmd at that msg's response/reply prompt that automatically reads
    the original post (#203 in this case.)

I thought I was "asking" the user that wanted true-reply threading, "How would
this be done?  Per msg?  Per user?  Per sub ORder?"
(Not suggesting, just asking.)

--797--

P> BA> Ken, I have the C source you released long ago for "WHO".
P> BA> Please consider releasing the current source also.
P> That source is current, you only need re-compile it with the new
P> headers..I did this long ago.

Are we looking at the same source?
Mine was from 1-2 YEARS ago.
Back long before WHO had the single char "M" "+" markers.
The "DL ETA times".
You can specify "WH2,4,6" to just show those lines.
And whatever else was added to WHO (or CNet) over the last 1-2 years.

Does your source have a datestamp?

--798--

Ken, v2.63 is now just displaying:
>No items matched.
>No items matched.
>No items matched.
>No items matched.
>No items matched.
>No items matched.
during searches without matches.  (RG 'FOOOO')

Not very informative.  Didn't it used to display the sub-names, too?
I'd love to see this as something like:
>Suggestions for the future:    No items matched.
>C program files:               No items matched.
>Other CNet Enhancement:        No items matched.
>Upload to Ken:                 No items atched.
>2.x updates:                   No items matched.
>Help me!:                      No item matched.
or a similar screen-space efficient display methods.

--799--

DM> quote that lists a specific message number is about as useful as tits on a
DM> boar hog on a network message area such as fido echos..
Maybe it could be part of the header text.
Only msgs posted on the original BBS would see it.
(It wouldn't be part of the Fidonet/Usenet msg text that gets sent out.)

Don, which *ARE* you allowing us?
1)  Quoting in local bases.
2)  A display that shows the quoted msg #.
3)  A "<" cmd that displays the original post.
Discourage one or two of them, but not all three.
Give us at least SOME way to know what a response is referring to.
Should we just guess?

If an item has 100-200 responses, it's a crap-shoot.

--EOF--

Tuesday, 23-Mar-93, 05:32:11

-Bill "Mr. BBS" Beogelein, 313-473-2020, 2-line HST 14.4k USR DS, 1:2410/207

