47 lines
2.6 KiB
Plaintext
47 lines
2.6 KiB
Plaintext
|
Considerations for FidoNet
|
|||
|
|
|
|||
|
|
As mentioned, one of the major drawbacks in the FidoNet project
|
|||
|
|
is the way by which it would be paid for. One of the
|
|||
|
|
possiblities is the 'Pay Ahead' method. The amount to be paid
|
|||
|
|
should most likely be a predetermined quantity of TJ Cubits. The
|
|||
|
|
application of the payment should be an entry, by the SysOp of
|
|||
|
|
the local Fido, into the USER.BBS file. This places the
|
|||
|
|
necessary information into a location that can be verified as a
|
|||
|
|
user utilizes their allocation of cubits. Each time an entry to
|
|||
|
|
the mail system is made, the available cubit quantity can be
|
|||
|
|
updated on a real time basis.
|
|||
|
|
|
|||
|
|
Another major problem is the verification of recieved mail. This
|
|||
|
|
applies not only to the FidoNet concept, but also to the message
|
|||
|
|
system as it exists in FidoBBS. A possible way of handling the
|
|||
|
|
transfer/receipt of remote mail, is to calculate the return
|
|||
|
|
message (received your message ### at FidoNet Location ###,
|
|||
|
|
time/date...) as part of the initial outgoing message. The
|
|||
|
|
local FidoMail system should in theory, check the senders
|
|||
|
|
USER.BBS record to determine the message area last used, and
|
|||
|
|
enter a message with the acknowledgement. As this pertains to
|
|||
|
|
local messages, when a message is entered, Fido could verify the
|
|||
|
|
name of the "To:" party, and the message area last used.
|
|||
|
|
|
|||
|
|
Another thing to be considered is the possiblity of automating SQ
|
|||
|
|
and LU modules in conjunction within a destination processor.
|
|||
|
|
This could squeeze all messages, and pack them into a library for
|
|||
|
|
each destination, cutting costs even further. If not to
|
|||
|
|
difficult, the receiving Fido could utilize a squeezed file
|
|||
|
|
interpreter to speed up the acknowledgement of receipt, as
|
|||
|
|
opposed to unsqueezing/de-lbr while on line. The only
|
|||
|
|
alternative would be for the remote Fido to call back an
|
|||
|
|
acknowledgement, shifting the cost to a location not receiving
|
|||
|
|
the payment.
|
|||
|
|
|
|||
|
|
The prospect of transferring, or as in another communication
|
|||
|
|
which shall remain un-named, "attachment" of program or data
|
|||
|
|
files would definately increase the potential value of FidoNet.
|
|||
|
|
This is especially true for club or commercial ventures. The
|
|||
|
|
problem becomes one of cost accounting. Would subscribers be
|
|||
|
|
willing to pay for a portion, pro-rated amount, of the transfer?
|
|||
|
|
Obviously a stickey point, but should be considered.
|
|||
|
|
|
|||
|
|
I certainly hope that this input is helpful. The possiblity of
|
|||
|
|
using this type of relay system is exciting! Hopefully it will
|
|||
|
|
be rewarding.
|