Don, I've opened this discussion up to a larger audience since the
resolution will effect many flwrap users.
Donald Kemp wrote:
Dave,
Too late, I uninstalled and reinstalled flwrap from your site.
No problem, didn't take long.
I did what you suggested and it did work OK.
I installed the flwrap on the other guy's computer
and I am reasonably sure he used flwrap because the old
WRAP was not installed. His fldigi did see the flwrap file
and saveed it to the correct directory but he got the same
encripted file when he dropped it through flwrap.
You must have installed the wrap executable on the regular web site and
not the alpha page Don. I just repeated the experiment with dropping
the file onto "wrap-1.0" which of course only yielded the compressed
file and not the original. On Linux this is a no brainer as the user
can then uncompress using the lzma compression tool. Some of the
windows compression tools might also work. That makes me quite certain
that the two ends are not using compatible versions of flwrap. The
confusion probably comes from my reusing the wrap icon for *fl*wrap.
We do not use the desktop icons, we install it into the quick
launch bar. Maybe that has something to do with it.
I've never tried it that way, but be advised that the program was
designed for use with a desktop icon launcher.
We have a directory for traffic to send and it has a flwrap shortcut in it
and it resids at the lower left of fldigi.
We then have the flwrap directory at the upper left of fldigi also
with a shortcut of flwrap in it.
When wrapped traffic comes in it appears in the flwrap directory;
it can then be dropped into that shortcut and the native file should appear.
This new file can be dragged into the send directory or into the
fldigi send buffer
is needed.
It all works very quickly and efficiently.
We will try again.
Sounds like you have a process that works for you.
However; having a file being transmitted as an incripted file
will not work for MARS.
Bad word ... encrypt ... a no no as far as the FCC is concerned. The
file is not encrypted, it is compressed using public domain compression
methods.
As a traffic rep, I would have to send the file twice,
once as a WRAP file and once as straight text. This only makes for
longer traffic
runs and wasts net time. Is it possible to make flwrap show normal text?
Why? When all of the users are using the same software would they not
all have the correct flwrap?
Will the old WRAP still work with the current Alpha version of fldigi?
Yes, but it will be deprecated by /*fl*wrap/.
What you really want is either the original wrap behavior or a software
switch that forces all data to be uncompressed if it originated as plain
ASCII text. Note that all images, binary data files (including MS Word
".doc" files) would still require compression and encoding using
base64. Because there are no "configuration" files for flwrap it would
be necessary to make that switch a command line switch. On Windows
XP/Vista/Win7 that would require that the launcher properties be changed
to include something like:
Target: "C:\Program Files\flwrap-1.0.2\flwrap.exe" --nocomp
I just checked on Vista and the Quick Launch bar also allows you to
change the properties in this manner.
It might be better to make the default without compression, since many
users seem to have minimal systems administration knowledge in the MS
world. Then the launch target properties would be:
Target: "C:\Program Files\flwrap-1.0.2\flwrap.exe" --usecomp
The purpose of compressing all files was to reduce the transmission
time. Files transferred using /flwrap/ contain data which must be
verified. If you are simply eyeballing the internal contents of the
wrapped file you are defeating its purpose. Why waste time with the
headers etc. Just transmit the original file and accept propagation
errors. If the data must be intact and verifiable then it makes no
difference whether you can read the data during transmission or not. If
it cannot be unwrapped correctly then the data is useless. A good
example might be a spreadsheet in comma separated value (.CSV) format
that contains numeric data. How would you verify this data without the
wrap technology. You would either have to repeat the file transmission
several times and then do voting, or the operators would have to verify
item-by-item.
Dave, W1HKJ
_______________________________________________
fldigi-alpha mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/fldigi-alpha
