As I wrote in my follow-up to your identical request
on Usenet, the way to
go about this is to perform the raw extraction on the server. If you view this request as a database table and you wish to extract selected row(s) from said table, the way to go about that is to have the server run some code that extracts the row(s) you want and download them.
This means that ftp itself does not need any real modification -- just smarter servers. I offered the U.K. mirror of Hobbes
as an example, but it
uses Web pages to offer the zip file's contents for selection. While http is somewhat slower than ftp, the difference over a
cable modem is sod all.
While http is somewhat slower than ftp, the difference
over a cable modem is sod all.
This means that ftp itself does not need any real modification --
just smarter servers. I offered the U.K. mirror of Hobbes as an
example, but it uses Web pages to offer the zip file's contents for
selection. While http is somewhat slower than ftp, the difference
over a cable modem is sod all.
You are totally correct, Dave, And the reason I didn't go forward
with what was offered there, is that it seems it's more civilized to
kick things around here in Fido, so I'll try to do that.
The problem, as I see it is in that last sentence you offered:
While http is somewhat slower than ftp, the difference
over a cable modem is sod all.
Under the conventional way of handling FTP for information and data recovery, we can recover a PAGE or PAGES of data.
When we see it
displayed on the download end, it is what is in the PAGE that is what
we see, Since the content in the page is accurate, the underpinning
file that is a part of it is transparent to the user, but is *NOT*
the same. It does not have the same date and time stamp as the
source.
HTTP has no underling method, which I know about, to match the file
date and time stamp between the systems,
file, or record, as a result of its file stamp time. We absolutely
have to maintain file stamp date and time,and, yes, in some case,
even the EA's, just to precisely match the information package
between the boxes!
Hi Mike,
Replying to a message of Mike Luther to David Noon:
I don't understand this. ftp shifts entire files
around. Did you mean http?
Now EA's *do* present a problem.
What you are asking for is a form of journalling and
recovery using ftp, or some moral equivalent.
Moreover, you need this processing to be so water-
tight that it will keep the FDA [and other government
departments around the world] happy as to its
accuracy. This is a job for which ftp is not really
suited.
Data recovery from journals is a task that is best handled by a program that makes the recovery as automatic as possible. This
program could use TCP/IP sockets for its "network tape
silo" instead of conventional tape [or other backup]
media. But its real smarts have to be in the way the
files to be recovered are identified. This should
require as little human interaction as possible. The
upshot is that some script wrapping an ftp client is
like using chewing gum and string where high tensile
steel is required.
The reason for this is that the DASD farm of the system to be recovered should not be trusted. Any client system that has been
compromised is really untrustworthy. This includes the
accuracy of file timestamps. The definitive source of
such information should be the journals on the
recovery server. This means that the recovery server
drives the entire operation.
Data propagation can be handled using the same tools.
The journalling activity can be used to propagate
files automatically as they change. The recovery
utility can be used to rebuild one system on another
machine by making the recovery parametric: change the
parameter that identifies the "lost" system, rather
than run with the current system's id.
For none of this is ftp a really suitable tool.
And that's one reason why Lotus Notes costs an arm and a leg!
And that's one reason why Lotus Notes costs an arm and a leg!
Regards
Dave
<Team PL/I>
Sleep well; OS/2's still awake! ;)
HTTP has no underling method, which I know about, to match the file
date and time stamp between the systems, [...]
If you use HTTP to create a maintenace database of files, names, dates and times, for example,to chart the on-going fix-everything for any OS/2 box,or
complicated system; you'll fail. That's because there is no way todisplay the
entire collection so that you are *SURE* that the file you have is theright one.
Sysop: | digital man |
---|---|
Location: | Riverside County, California |
Users: | 1,028 |
Nodes: | 17 (1 / 16) |
Uptime: | 182:43:06 |
Calls: | 503,706 |
Calls today: | 9 |
Files: | 158,907 |
D/L today: |
16,133 files (4,812M bytes) |
Messages: | 444,385 |
Posted today: | 3 |