wwiv
wwiv copied to clipboard
Implement main_type_new_external
If we bring this back, it'll make it easier to integrate with some intrabbs tools
Here's the text from the net38 tech docs:
main_type 27 (0x001b) -- main_type_new_external
This is the new type of external message,
implemented with NET33. Like main_type 6, it
creates an external file with the message text for
an external program to process. Again, the
minor_type is determined by the external program.
There is a full explanation of how these messages
are processed in Filo's NETXX Software Docs. In
short, similar to main_type 6, the local mail
processor searches for the minor_type in a data file
(EPROGS.NET for NETxx), and creates an external file
if it is found. When the local mail processor is
finished with the local mail file, the program
associated with that minor_type will execute, with
the associated filename (with path) as a parameter.
and in the non-tech docs:
Appendix I - External Message Interface
======================================================
Net33 (and later versions) will include a method whereby
messages for external programs can be transferred through
the network. This does not describe how to read network
data files, or how to write net packets, only how to
integrate a program that does those things with the
network. (see the WWIV source code, or WWIVnet technical
docs, for info on that.)
All received message packets that are destined for the
local system are stored into "LOCAL.NET" in your network
data directory. The network2.exe program is then run to
process the messages. If any messages are of the "new
external" type (main_type_new_extern, 0x001b), then they
may be saved for processing by an external net program.
Each external network program requires a program (.exe
or .com, NOT .bat), which will take as parameters a
filename of a network file (p*.net format), and a network
number identifier (.net_num). Each external network
program can take as input a contiguous range of
minor_type's.
External network programs are described in the
'EPROGS.NET' which (optionally) exists in the network data
directory. The eprogs.net file is a text file, and has a
line describing one external net program per line. Each
line has three pieces of information: the program name
(1-8 chars), the starting minor_type, and the stopping
minor_type. So, for example, if an external net program
'netprog.exe' is to handle main_type 0x1b, minor types
100-103, then the line in the eprogs.net file for that
processor would be:
netprog 100 103
(If the program handles only one minor_type, then the
starting and stopping minor_types should both be the same,
and equal to the minor_type to be processed.)
As local.net is processed, any main_type_new_extern
messages encountered cause network2 to search the
eprogs.net file to see if any external net programs are
set up to handle that minor_type. If none are found, the
net message is thrown away. If there are two or more
programs listed to process that minor_type, only the first
receives the message. Net messages accepted for an
external net program are stored to a temporary file while
local.net has been processed. After local.net has been
completely processed, and deleted, network2 runs the
external net programs, in order, passing them the
filename of the temporary net file for that program, and
an indication of which network is being processed. After
the program exits, the temporary net file is deleted.
Note that it IS allowable for an external net program
to create a p*.net file for outgoing messages, OR to put
net messages to the local.net file which will be
immediately re-processed by the BBS.
Please do not blindly grab minor_types. If you need a
lot of separate message types, the message type can be
stored in the text part of the message and a single
minor_type used instead.
There are also local.net pre-processors allowed in
net32. The preprocessors are listed in the 'epreproc.net'
file in the network data directory, one per line. BEFORE
network2 processes ANY of local.net, each preprocessor is
run, in order, passing each the ".net_num" parameter to
indicate which network is being processed. The pre-
processor may then scan through local.net, and mark as
deleted (main_type=65535) any message processed by that
preprocessor. The preprocessor may even append additional
messages to the local.net file, if that is desired.
Sounds great! Can help with implementing bbs to e-mail integration for notifications etc…? Like what was in WINS/NEWS from the old PPP project days?
I started work on something that needed the EPROGS.NET before then saw that it wasn't implemented yet. This will be cool for a lot of stuff that we can make for WWIVnet.
It doesn't seem to hard to implement I think, the temp files that are passed to the binary listed in eprogs.net are just wwivnet packet format files. The programs get called like
"program" tempXXXX.net .1 (assuming the network number is 1)
@ericpareja I guess a question is do we want it to work exactly the same now, is there something we could do to make it easier to use?
https://github.com/wwiv/wwiv/commit/415a61975681a102bf6bfdd5ed74bebfb21c1e26 is what I think is likely 90% of eprogs support. I'll need to add some tests and cleanup a bit before merging. feedback welcome
It's still not perfect, but I merged it in if you wanted to check it out
This has been merged, old style eprogs.net support exists.
This is in 5.8