Re:Re: Re: Optimizing cutting paths - The proof
Posted by
Fred Smith
on 2001-09-02 09:50:32 UTC
--- In CAD_CAM_EDM_DRO@y..., "Art Fenerty" <fenerty@h...> wrote:
will rephrase my statement so that there is no question about coming
in on the middle of a conversation and taking a response to a
statement out of context.
1) There are situations that people want to communicate DXF files
from one location to another.
2)They sometimes have problems doing this successfully. They usually
also don't know why, so they blame it on what a poor format DXF is,
what a poor CAD program they have, or they just know it doesn't work,
but don't know why.
Any arguments so far?
3)If the original file is Zipped by the owner and sent to the
recipient and the file can be successfully opened the problem is
solved. Correct?
Who cares if the problem is caused by lousy internet wiring, routers,
poor transmission algorithms, windows and linux warriors, worms,
filled hard drives, disconnected dialups, hackers, Windows OS
glitches, or any other excuse? Not the guy sending and not the guy
receiving. They only want a good file. Guess what, zipping the file
eliminates ALL the excuses and fingerpointing. It either arrives in
good shape and unzips, or it doesn't. The guy at the sending end can
unzip his file and test it to make sure that it was good starting
out. There is no worry about mission critical data, as it will not
unzip if there are missing parts. Why it can even be password
protected if needed for additional security.
The danger is not in transmitting text vs binary, the danger is in
not receiving the whole package, and not knowing about it. The very
discussion we are having is as a result of Alan not being able to
download files from John's website. John said his ISP had trouble.
I could download the files but Alan could not. When John zipped the
files Alan had no more trouble, in fact was probably able to download
all 6 or 8 files in less time than the original text only.
Why take issue with my recommendation? It is a simple, valid,
inexpensive, secure method to communicate, large volumes of mission
critical text data over the internet or any other wired network. It
requires no technical support for the end users to effect a secure
system under their own control.
Best Regards,
Fred Smith
IMService
> Fred:dangerous to
>
> With all due respect, I have to disagree, Text is no more
> transmit than Zip's Binary files or anything else. Static, etc. hasNO
> influence on a file transmission. This is not an experience issue,it is one
> of electronics and networking.All right since we are not all speaking the same language here, I
will rephrase my statement so that there is no question about coming
in on the middle of a conversation and taking a response to a
statement out of context.
1) There are situations that people want to communicate DXF files
from one location to another.
2)They sometimes have problems doing this successfully. They usually
also don't know why, so they blame it on what a poor format DXF is,
what a poor CAD program they have, or they just know it doesn't work,
but don't know why.
Any arguments so far?
3)If the original file is Zipped by the owner and sent to the
recipient and the file can be successfully opened the problem is
solved. Correct?
Who cares if the problem is caused by lousy internet wiring, routers,
poor transmission algorithms, windows and linux warriors, worms,
filled hard drives, disconnected dialups, hackers, Windows OS
glitches, or any other excuse? Not the guy sending and not the guy
receiving. They only want a good file. Guess what, zipping the file
eliminates ALL the excuses and fingerpointing. It either arrives in
good shape and unzips, or it doesn't. The guy at the sending end can
unzip his file and test it to make sure that it was good starting
out. There is no worry about mission critical data, as it will not
unzip if there are missing parts. Why it can even be password
protected if needed for additional security.
The danger is not in transmitting text vs binary, the danger is in
not receiving the whole package, and not knowing about it. The very
discussion we are having is as a result of Alan not being able to
download files from John's website. John said his ISP had trouble.
I could download the files but Alan could not. When John zipped the
files Alan had no more trouble, in fact was probably able to download
all 6 or 8 files in less time than the original text only.
Why take issue with my recommendation? It is a simple, valid,
inexpensive, secure method to communicate, large volumes of mission
critical text data over the internet or any other wired network. It
requires no technical support for the end users to effect a secure
system under their own control.
Best Regards,
Fred Smith
IMService
Discussion Thread
machines@n...
2001-08-30 15:11:00 UTC
Optimizing cutting paths - The proof
Alan Marconett KM6VV
2001-08-30 16:09:17 UTC
Re: [CAD_CAM_EDM_DRO] Optimizing cutting paths - The proof
machines@n...
2001-08-30 16:33:59 UTC
Re: Optimizing cutting paths - The proof
Alan Marconett KM6VV
2001-08-30 18:52:26 UTC
Re: Optimizing cutting paths - The proof
Chris L
2001-08-30 19:27:21 UTC
Re: [CAD_CAM_EDM_DRO] Optimizing cutting paths - The proof
Chris L
2001-08-30 19:30:35 UTC
Re: [CAD_CAM_EDM_DRO] Re: Optimizing cutting paths - The proof
Alan Marconett KM6VV
2001-08-30 20:43:47 UTC
Re: Optimizing cutting paths - The proof
machines@n...
2001-08-31 00:53:59 UTC
Re: Optimizing cutting paths - The proof
machines@n...
2001-08-31 00:59:19 UTC
Re: Optimizing cutting paths - The proof
Carlos Guillermo
2001-08-31 05:26:03 UTC
RE: [CAD_CAM_EDM_DRO] Re: Optimizing cutting paths - The proof
Fred Smith
2001-08-31 05:39:41 UTC
Re: Optimizing cutting paths - The proof
machines@n...
2001-08-31 09:47:17 UTC
Re: Optimizing cutting paths - The proof
Alan Marconett KM6VV
2001-08-31 10:16:07 UTC
Re: Optimizing cutting paths - The proof
Alan Marconett KM6VV
2001-08-31 11:33:31 UTC
Re: Optimizing cutting paths - The proof
Chris Luebke
2001-08-31 12:23:54 UTC
Re: [CAD_CAM_EDM_DRO] Re: Optimizing cutting paths - The proof
machines@n...
2001-08-31 12:26:51 UTC
Re: Optimizing cutting paths - The proof
Alan Marconett KM6VV
2001-08-31 13:46:31 UTC
Re: Optimizing cutting paths - The proof
Alan Marconett KM6VV
2001-08-31 13:53:19 UTC
Re: Optimizing cutting paths - The proof
Fred Smith
2001-08-31 14:23:38 UTC
Re: Optimizing cutting paths - The proof
wanliker@a...
2001-08-31 15:07:19 UTC
Re: [CAD_CAM_EDM_DRO] Re: Optimizing cutting paths - The proof
wanliker@a...
2001-08-31 15:07:29 UTC
Re: [CAD_CAM_EDM_DRO] Re: Optimizing cutting paths - The proof
Peter Harrison
2001-09-01 16:26:06 UTC
Re: [CAD_CAM_EDM_DRO] Re: Optimizing cutting paths - The proof
Jon Elson
2001-09-01 17:35:37 UTC
Re: [CAD_CAM_EDM_DRO] Re: Optimizing cutting paths - The proof
Peter Harrison
2001-09-02 05:26:48 UTC
Re: [CAD_CAM_EDM_DRO] Re: Optimizing cutting paths - The proof
IMService
2001-09-02 06:19:28 UTC
Re:Re: Re: Optimizing cutting paths - The proof
Art Fenerty
2001-09-02 06:44:03 UTC
Re: [CAD_CAM_EDM_DRO] Re:Re: Re: Optimizing cutting paths - The proof
Tony Jeffree
2001-09-02 09:46:37 UTC
Re: Optimizing cutting paths - The proof
Fred Smith
2001-09-02 09:50:32 UTC
Re:Re: Re: Optimizing cutting paths - The proof
cncdxf@a...
2001-09-02 10:56:38 UTC
Re:Re: Re: Optimizing cutting paths - The proof
machines@n...
2001-09-02 11:31:28 UTC
Re:Re: Re: Optimizing cutting paths - The proof
cncdxf@a...
2001-09-02 13:26:21 UTC
Re:Re: Re: Optimizing cutting paths - The proof
Art Fenerty
2001-09-02 13:46:58 UTC
Re: [CAD_CAM_EDM_DRO] Re:Re: Re: Optimizing cutting paths - The proof
wanliker@a...
2001-09-02 14:09:54 UTC
Re: [CAD_CAM_EDM_DRO] Re:Re: Re: Optimizing cutting paths - The proof
wanliker@a...
2001-09-02 14:13:54 UTC
Re: [CAD_CAM_EDM_DRO] Re:Re: Re: Optimizing cutting paths - The proof
Gail & Bryan Harries
2001-09-02 14:41:43 UTC
RE: [CAD_CAM_EDM_DRO] Re:Re: Re: Optimizing cutting paths - The proof
Art Fenerty
2001-09-02 14:49:51 UTC
Re: [CAD_CAM_EDM_DRO] Re: Optimizing cutting paths - The proof
rab@r...
2001-09-02 15:00:12 UTC
Re:Re: Re: Optimizing cutting paths