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. |