[nos-bbs] Questions related to JNOS 1.11f

[Miroslav Skoric (YT7MPB)]

Barry Siegfried wrote:

> 
> Yes, I suppose that would work.  Is the FBB source "open"?  No doubt
> such a subroutine could be ported to JNOS if somebody has enough of
> an interest to do it.  My prediction is, however, that this will not
> happen.
> 
Not quite sure about but think that only Linux version of FBB is open 
source. Anyway, I recall that in fact it wasn't a 'subroutine' of FBB 
itself but rather an external add-on called SCANBULL or something like 
that. If I remembers properly, it was run in DodFBB's background and 
acted upon the user's input (say, I am looking for bulletins having the 
word 'radio') in a special message sent to the server. The sender would, 
later, get the response from FBB, a list with such bulletins.

> The reason that there is no such "manual" is because there are
> limitless possibilities for "specific NOS usage".  Everyone has
> different needs and therefore uses NOS in a different manner, which
> means that everyone's CONFIG.H file must be specific in order to
> provide what they require.
> 

Barry, you are right generally speaking. But I am sure that all those 
"different needs" may be grouped into 5-6 main groups (mailbox on plain 
packet, mailbox for both packet and TCPIP, gateway/router, only router 
etc). Of course, we all mostly dislike to document what we are doing 
while trying to setup and configure our own experimenting systems. If 
opposite - a lot of experience would be documented and posted in a form 
of manual or something. I myself keep maintaining a FBB howto document 
that I am sure is far from perfect but many told me that even then it 
helped to start with the software.

> I have more than 20 different CONFIG.H files in the source code
> directories here which hold them, and of those 25, whenever I have
> to compile a new or changed program I run a batch procedure that
> automatically compiles all of them.  Then I have to distribute
> them after they are compiled which is the fun part...
> 
That great but if you (or somebody close to you) is able to document the 
features and/or installation procedure of what you have in your 
repositories, that might help the others and save you some time of 
answering to reinventing-the-wheels-type of questions :-)

> That is because SMTP has the distinction of being a service
> for which the client and server are so dependent upon each other that
> you literally cannot have one without the other.  And many of the mail
> receive handling routines that are used in the mailbox use subroutine
> mechanics that are common to the SMTP server as well.  So if you
> #undefine SMTP mail handling then you will #undefine mailbox mail
> handling as well.
> 

Yes I know that now but I have learned that a hard way. Once again, if I 
could find a manual having a warning on those details you discuss, it 
would be much easier to start.

> I have my own CONFIG.H setup "reverse" from that kind of logic, however
> to make it as difficult as possible to disable anything you actually
> need for your configuration.  For instance, even if you #undefine the
> SMTP client or server, if you #define one of them then the other is
> forcibly #defined and if you #define mailbox mail handling then both
> the SMTP client and server are forcibly #defined as well.  This way
> you aren't left with a program that won't do what you really want or
> need it to do.
> 

Do you think ... they are "forcibly #defined" during the compilation 
process - regardless what is defined (or not) within config.h ? Sounds 
interesting if during the compilation there is a 'watchdog' in a 
compiler - looking for what you might have set up as a wrong parameter 
(say, some mutually exclusive program options).

Regards,

Misko